[PATCH v2 0/3] dmaengine: ti: k3-udma: memcpy throughput improvement
Hi, Changes since v1: - Added Kishon's tested-by to the first two patch - Moved the variable definitions to the start of their respective functions - Remove braces where they are not needed - correct indentation of cases - additional patch to clean up the ret = 0 initializations in tisci channel configuration functions, no functional changes. Newer members of the KS3 family (after AM654) have support for burst_size configuration for each DMA channel. The HW default value is 64 bytes but on higher throughput channels it can be increased to 256 bytes (UCHANs) or 128 byes (HCHANs). Aligning the buffers and length of the transfer to the burst size also increases the throughput. Numbers gathered on j721e (UCHAN pair): echo 800 > /sys/module/dmatest/parameters/test_buf_size echo 2000 > /sys/module/dmatest/parameters/timeout echo 50 > /sys/module/dmatest/parameters/iterations echo 1 > /sys/module/dmatest/parameters/max_channels Prior to this patch: ~1.3 GB/s After this patch: ~1.8 GB/s with 1 byte alignment: ~1.7 GB/s Regards, Peter --- Peter Ujfalusi (3): dmaengine: Extend the dmaengine_alignment for 128 and 256 bytes dmaengine: ti: k3-udma: Add support for burst_size configuration for mem2mem dmaengine: ti: k3-udma: Do not initialize ret in tisci channel config functions drivers/dma/ti/k3-udma.c | 130 ++ include/linux/dmaengine.h | 2 + 2 files changed, 120 insertions(+), 12 deletions(-) -- 2.30.0
[PATCH v2 2/3] dmaengine: ti: k3-udma: Add support for burst_size configuration for mem2mem
From: Peter Ujfalusi
The UDMA and BCDMA can provide higher throughput if the burst_size of the
channel is changed from it's default (which is 64 bytes) for Ultra-high
and high capacity channels.
This performance benefit is even more visible when the buffers are aligned
with the burst_size configuration.
The am654 does not have a way to change the burst size, but it is using
64 bytes burst, so increasing the copy_align from 8 bytes to 64 (and
clients taking that into account) can increase the throughput as well.
Numbers gathered on j721e:
echo 800 > /sys/module/dmatest/parameters/test_buf_size
echo 2000 > /sys/module/dmatest/parameters/timeout
echo 50 > /sys/module/dmatest/parameters/iterations
echo 1 > /sys/module/dmatest/parameters/max_channels
Prior this patch: ~1.3 GB/s
After this patch: ~1.8 GB/s
with 1 byte alignment: ~1.7 GB/s
Signed-off-by: Peter Ujfalusi
Signed-off-by: Peter Ujfalusi
Tested-by: Kishon Vijay Abraham I
---
drivers/dma/ti/k3-udma.c | 116 +--
1 file changed, 111 insertions(+), 5 deletions(-)
diff --git a/drivers/dma/ti/k3-udma.c b/drivers/dma/ti/k3-udma.c
index 298460438bb4..1030c2ff487a 100644
--- a/drivers/dma/ti/k3-udma.c
+++ b/drivers/dma/ti/k3-udma.c
@@ -121,6 +121,11 @@ struct udma_oes_offsets {
#define UDMA_FLAG_PDMA_ACC32 BIT(0)
#define UDMA_FLAG_PDMA_BURST BIT(1)
#define UDMA_FLAG_TDTYPE BIT(2)
+#define UDMA_FLAG_BURST_SIZE BIT(3)
+#define UDMA_FLAGS_J7_CLASS(UDMA_FLAG_PDMA_ACC32 | \
+UDMA_FLAG_PDMA_BURST | \
+UDMA_FLAG_TDTYPE | \
+UDMA_FLAG_BURST_SIZE)
struct udma_match_data {
enum k3_dma_type type;
@@ -128,6 +133,7 @@ struct udma_match_data {
bool enable_memcpy_support;
u32 flags;
u32 statictr_z_mask;
+ u8 burst_size[3];
};
struct udma_soc_data {
@@ -436,6 +442,18 @@ static void k3_configure_chan_coherency(struct dma_chan
*chan, u32 asel)
}
}
+static u8 udma_get_chan_tpl_index(struct udma_tpl *tpl_map, int chan_id)
+{
+ int i;
+
+ for (i = 0; i < tpl_map->levels; i++) {
+ if (chan_id >= tpl_map->start_idx[i])
+ return i;
+ }
+
+ return 0;
+}
+
static void udma_reset_uchan(struct udma_chan *uc)
{
memset(>config, 0, sizeof(uc->config));
@@ -1811,13 +1829,21 @@ static int udma_tisci_m2m_channel_config(struct
udma_chan *uc)
const struct ti_sci_rm_udmap_ops *tisci_ops = tisci_rm->tisci_udmap_ops;
struct udma_tchan *tchan = uc->tchan;
struct udma_rchan *rchan = uc->rchan;
+ u8 burst_size = 0;
int ret = 0;
+ u8 tpl;
/* Non synchronized - mem to mem type of transfer */
int tc_ring = k3_ringacc_get_ring_id(tchan->tc_ring);
struct ti_sci_msg_rm_udmap_tx_ch_cfg req_tx = { 0 };
struct ti_sci_msg_rm_udmap_rx_ch_cfg req_rx = { 0 };
+ if (ud->match_data->flags & UDMA_FLAG_BURST_SIZE) {
+ tpl = udma_get_chan_tpl_index(>tchan_tpl, tchan->id);
+
+ burst_size = ud->match_data->burst_size[tpl];
+ }
+
req_tx.valid_params = TISCI_UDMA_TCHAN_VALID_PARAMS;
req_tx.nav_id = tisci_rm->tisci_dev_id;
req_tx.index = tchan->id;
@@ -1825,6 +1851,10 @@ static int udma_tisci_m2m_channel_config(struct
udma_chan *uc)
req_tx.tx_fetch_size = sizeof(struct cppi5_desc_hdr_t) >> 2;
req_tx.txcq_qnum = tc_ring;
req_tx.tx_atype = ud->atype;
+ if (burst_size) {
+ req_tx.valid_params |=
TI_SCI_MSG_VALUE_RM_UDMAP_CH_BURST_SIZE_VALID;
+ req_tx.tx_burst_size = burst_size;
+ }
ret = tisci_ops->tx_ch_cfg(tisci_rm->tisci, _tx);
if (ret) {
@@ -1839,6 +1869,10 @@ static int udma_tisci_m2m_channel_config(struct
udma_chan *uc)
req_rx.rxcq_qnum = tc_ring;
req_rx.rx_chan_type = TI_SCI_RM_UDMAP_CHAN_TYPE_3RDP_BCOPY_PBRR;
req_rx.rx_atype = ud->atype;
+ if (burst_size) {
+ req_rx.valid_params |=
TI_SCI_MSG_VALUE_RM_UDMAP_CH_BURST_SIZE_VALID;
+ req_rx.rx_burst_size = burst_size;
+ }
ret = tisci_ops->rx_ch_cfg(tisci_rm->tisci, _rx);
if (ret)
@@ -1854,12 +1888,24 @@ static int bcdma_tisci_m2m_channel_config(struct
udma_chan *uc)
const struct ti_sci_rm_udmap_ops *tisci_ops = tisci_rm->tisci_udmap_ops;
struct ti_sci_msg_rm_udmap_tx_ch_cfg req_tx = { 0 };
struct udma_bchan *bchan = uc->bchan;
+ u8 burst_size = 0;
int ret = 0;
+ u8 tpl;
+
+ if (ud->match_data->flags & UDMA_FLAG_BURST_SIZE) {
+ tpl = udma_get_chan_tpl_index(>bchan_tpl, bchan->id);
+
+ burst_size = ud->match
[PATCH v2 1/3] dmaengine: Extend the dmaengine_alignment for 128 and 256 bytes
From: Peter Ujfalusi
Some DMA device can benefit with higher order of alignment than the maximum
of 64 bytes currently defined.
Define 128 and 256 bytes alignment for these devices.
Signed-off-by: Peter Ujfalusi
Signed-off-by: Peter Ujfalusi
Tested-by: Kishon Vijay Abraham I
---
include/linux/dmaengine.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/include/linux/dmaengine.h b/include/linux/dmaengine.h
index 68130f5f599e..004736b6a9c8 100644
--- a/include/linux/dmaengine.h
+++ b/include/linux/dmaengine.h
@@ -745,6 +745,8 @@ enum dmaengine_alignment {
DMAENGINE_ALIGN_16_BYTES = 4,
DMAENGINE_ALIGN_32_BYTES = 5,
DMAENGINE_ALIGN_64_BYTES = 6,
+ DMAENGINE_ALIGN_128_BYTES = 7,
+ DMAENGINE_ALIGN_256_BYTES = 8,
};
/**
--
2.30.0
[PATCH v2 3/3] dmaengine: ti: k3-udma: Do not initialize ret in tisci channel config functions
The ret does not need to be initialized to 0 in the tisci channel config
functions.
Signed-off-by: Peter Ujfalusi
---
drivers/dma/ti/k3-udma.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/dma/ti/k3-udma.c b/drivers/dma/ti/k3-udma.c
index 1030c2ff487a..4c0935c6930c 100644
--- a/drivers/dma/ti/k3-udma.c
+++ b/drivers/dma/ti/k3-udma.c
@@ -1830,7 +1830,7 @@ static int udma_tisci_m2m_channel_config(struct udma_chan
*uc)
struct udma_tchan *tchan = uc->tchan;
struct udma_rchan *rchan = uc->rchan;
u8 burst_size = 0;
- int ret = 0;
+ int ret;
u8 tpl;
/* Non synchronized - mem to mem type of transfer */
@@ -1889,7 +1889,7 @@ static int bcdma_tisci_m2m_channel_config(struct
udma_chan *uc)
struct ti_sci_msg_rm_udmap_tx_ch_cfg req_tx = { 0 };
struct udma_bchan *bchan = uc->bchan;
u8 burst_size = 0;
- int ret = 0;
+ int ret;
u8 tpl;
if (ud->match_data->flags & UDMA_FLAG_BURST_SIZE) {
@@ -1923,7 +1923,7 @@ static int udma_tisci_tx_channel_config(struct udma_chan
*uc)
int tc_ring = k3_ringacc_get_ring_id(tchan->tc_ring);
struct ti_sci_msg_rm_udmap_tx_ch_cfg req_tx = { 0 };
u32 mode, fetch_size;
- int ret = 0;
+ int ret;
if (uc->config.pkt_mode) {
mode = TI_SCI_RM_UDMAP_CHAN_TYPE_PKT_PBRR;
@@ -1964,7 +1964,7 @@ static int bcdma_tisci_tx_channel_config(struct udma_chan
*uc)
const struct ti_sci_rm_udmap_ops *tisci_ops = tisci_rm->tisci_udmap_ops;
struct udma_tchan *tchan = uc->tchan;
struct ti_sci_msg_rm_udmap_tx_ch_cfg req_tx = { 0 };
- int ret = 0;
+ int ret;
req_tx.valid_params = TISCI_BCDMA_TCHAN_VALID_PARAMS;
req_tx.nav_id = tisci_rm->tisci_dev_id;
@@ -1997,7 +1997,7 @@ static int udma_tisci_rx_channel_config(struct udma_chan
*uc)
struct ti_sci_msg_rm_udmap_rx_ch_cfg req_rx = { 0 };
struct ti_sci_msg_rm_udmap_flow_cfg flow_req = { 0 };
u32 mode, fetch_size;
- int ret = 0;
+ int ret;
if (uc->config.pkt_mode) {
mode = TI_SCI_RM_UDMAP_CHAN_TYPE_PKT_PBRR;
@@ -2074,7 +2074,7 @@ static int bcdma_tisci_rx_channel_config(struct udma_chan
*uc)
const struct ti_sci_rm_udmap_ops *tisci_ops = tisci_rm->tisci_udmap_ops;
struct udma_rchan *rchan = uc->rchan;
struct ti_sci_msg_rm_udmap_rx_ch_cfg req_rx = { 0 };
- int ret = 0;
+ int ret;
req_rx.valid_params = TISCI_BCDMA_RCHAN_VALID_PARAMS;
req_rx.nav_id = tisci_rm->tisci_dev_id;
@@ -2094,7 +2094,7 @@ static int pktdma_tisci_rx_channel_config(struct
udma_chan *uc)
const struct ti_sci_rm_udmap_ops *tisci_ops = tisci_rm->tisci_udmap_ops;
struct ti_sci_msg_rm_udmap_rx_ch_cfg req_rx = { 0 };
struct ti_sci_msg_rm_udmap_flow_cfg flow_req = { 0 };
- int ret = 0;
+ int ret;
req_rx.valid_params = TISCI_BCDMA_RCHAN_VALID_PARAMS;
req_rx.nav_id = tisci_rm->tisci_dev_id;
--
2.30.0
[PATCH v2] dt-bindings: display: bridge: tc358768: Change maintainer information
My employment with TI is coming to an end and I will not have access to the board where this bridge is connected to and I will also loose access to the manual of the chip. Add the missing copyright information, author and change the maintainer to Sam Ravnborg (thank you for volenteering!) Signed-off-by: Peter Ujfalusi --- .../devicetree/bindings/display/bridge/toshiba,tc358768.yaml | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/display/bridge/toshiba,tc358768.yaml b/Documentation/devicetree/bindings/display/bridge/toshiba,tc358768.yaml index c036a75db8f7..c08fd42be2d0 100644 --- a/Documentation/devicetree/bindings/display/bridge/toshiba,tc358768.yaml +++ b/Documentation/devicetree/bindings/display/bridge/toshiba,tc358768.yaml @@ -1,4 +1,6 @@ # SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +# Copyright (C) 2020 Texas Instruments Incorporated +# Author: Peter Ujfalusi %YAML 1.2 --- $id: http://devicetree.org/schemas/display/bridge/toshiba,tc358768.yaml# @@ -7,7 +9,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: Toschiba TC358768/TC358778 Parallel RGB to MIPI DSI bridge maintainers: - - Peter Ujfalusi + - Sam Ravnborg description: | The TC358768/TC358778 is bridge device which converts RGB to DSI. -- Peter Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
Re: [PATCH] dt-bindings: display: bridge: tc358768: Remove maintainer information
Hi Sam, On 17/12/2020 19.25, Sam Ravnborg wrote: >>> dtschema/dtc warnings/errors: >>> /builds/robherring/linux-dt-review/Documentation/devicetree/bindings/display/bridge/toshiba,tc358768.yaml: >>> 'maintainers' is a required property >>> /builds/robherring/linux-dt-review/Documentation/devicetree/bindings/display/bridge/toshiba,tc358768.yaml: >>> ignoring, error in schema: >>> warning: no schema found in file: >>> ./Documentation/devicetree/bindings/display/bridge/toshiba,tc358768.yaml >> >> Right, so it is not that easy to not been able to maintain this... :o >> >> Who should be documented as maintainer? >> Andrzej, Neil, David or Daniel? > > I have no problem being listed as maintainer despite my very limited > knowledge on the HW. So unless you end up volunteering then just > add me. thank you. it is not easy to give up on something one has spent time on, but without the hardware and manual it would be not right to just move it to my private email as I did for the DMA and Audio drivers: https://lore.kernel.org/lkml/20201215130512.8753-1-peter.ujfal...@ti.com/ https://lore.kernel.org/lkml/20201215131348.11282-1-peter.ujfal...@ti.com/ I'll send v2 as may last patch from ti.com - Péter Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
[PATCH] dmaengine: ti: k3-udma: Fix pktdma rchan TPL level setup
Instead of initializing the rchan_tpl the initial commit re-initialized
the tchan_tpl.
Fixes: d2abc982333c0 ("dmaengine: ti: k3-udma: Initial support for K3 PKTDMA")
Signed-off-by: Peter Ujfalusi
---
drivers/dma/ti/k3-udma.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/dma/ti/k3-udma.c b/drivers/dma/ti/k3-udma.c
index d4ab7f144c75..aa6186a1223d 100644
--- a/drivers/dma/ti/k3-udma.c
+++ b/drivers/dma/ti/k3-udma.c
@@ -4774,9 +4774,9 @@ static int pktdma_setup_resources(struct udma_dev *ud)
ud->tchan_tpl.levels = 1;
}
- ud->tchan_tpl.levels = ud->tchan_tpl.levels;
- ud->tchan_tpl.start_idx[0] = ud->tchan_tpl.start_idx[0];
- ud->tchan_tpl.start_idx[1] = ud->tchan_tpl.start_idx[1];
+ ud->rchan_tpl.levels = ud->tchan_tpl.levels;
+ ud->rchan_tpl.start_idx[0] = ud->tchan_tpl.start_idx[0];
+ ud->rchan_tpl.start_idx[1] = ud->tchan_tpl.start_idx[1];
ud->tchan_map = devm_kmalloc_array(dev, BITS_TO_LONGS(ud->tchan_cnt),
sizeof(unsigned long), GFP_KERNEL);
--
Peter
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
Re: [PATCH] dt-bindings: display: bridge: tc358768: Remove maintainer information
On 15/12/2020 16.26, Rob Herring wrote: > On Tue, 15 Dec 2020 14:42:27 +0200, Peter Ujfalusi wrote: >> My employment with TI is coming to an end and I will not have access to >> the board where this bridge is connected to. >> >> It is better to remove a soon bouncing email address. >> >> Signed-off-by: Peter Ujfalusi >> --- >> .../devicetree/bindings/display/bridge/toshiba,tc358768.yaml | 3 --- >> 1 file changed, 3 deletions(-) >> > > My bot found errors running 'make dt_binding_check' on your patch: > > yamllint warnings/errors: > > dtschema/dtc warnings/errors: > /builds/robherring/linux-dt-review/Documentation/devicetree/bindings/display/bridge/toshiba,tc358768.yaml: > 'maintainers' is a required property > /builds/robherring/linux-dt-review/Documentation/devicetree/bindings/display/bridge/toshiba,tc358768.yaml: > ignoring, error in schema: > warning: no schema found in file: > ./Documentation/devicetree/bindings/display/bridge/toshiba,tc358768.yaml Right, so it is not that easy to not been able to maintain this... :o Who should be documented as maintainer? Andrzej, Neil, David or Daniel? I will have no access to the EVM (I no longer have) and the documentation is going to be wiped along with the disk as well... > See https://patchwork.ozlabs.org/patch/1416419 > > This check can fail if there are any dependencies. The base for a patch > series is generally the most recent rc1. > > If you already ran 'make dt_binding_check' and didn't see the above > error(s), then make sure 'yamllint' is installed and dt-schema is up to > date: > > pip3 install dtschema --upgrade > > Please check and re-submit. > - Péter Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
[PATCH 2/2] dt-bindings: dma: ti: Update maintainer and author information
My employment with TI is coming to an end, add the copyright and author comments as they due and change the maintainer mail address. Signed-off-by: Peter Ujfalusi Signed-off-by: Peter Ujfalusi --- Documentation/devicetree/bindings/dma/ti/k3-bcdma.yaml | 4 +++- Documentation/devicetree/bindings/dma/ti/k3-pktdma.yaml | 4 +++- Documentation/devicetree/bindings/dma/ti/k3-udma.yaml | 4 +++- 3 files changed, 9 insertions(+), 3 deletions(-) diff --git a/Documentation/devicetree/bindings/dma/ti/k3-bcdma.yaml b/Documentation/devicetree/bindings/dma/ti/k3-bcdma.yaml index b15f68c499cb..df29d59d13a8 100644 --- a/Documentation/devicetree/bindings/dma/ti/k3-bcdma.yaml +++ b/Documentation/devicetree/bindings/dma/ti/k3-bcdma.yaml @@ -1,4 +1,6 @@ # SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +# Copyright (C) 2020 Texas Instruments Incorporated +# Author: Peter Ujfalusi %YAML 1.2 --- $id: http://devicetree.org/schemas/dma/ti/k3-bcdma.yaml# @@ -7,7 +9,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: Texas Instruments K3 DMSS BCDMA Device Tree Bindings maintainers: - - Peter Ujfalusi + - Peter Ujfalusi description: | The Block Copy DMA (BCDMA) is intended to perform similar functions as the TR diff --git a/Documentation/devicetree/bindings/dma/ti/k3-pktdma.yaml b/Documentation/devicetree/bindings/dma/ti/k3-pktdma.yaml index b13ab60cd740..ea19d12a9337 100644 --- a/Documentation/devicetree/bindings/dma/ti/k3-pktdma.yaml +++ b/Documentation/devicetree/bindings/dma/ti/k3-pktdma.yaml @@ -1,4 +1,6 @@ # SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +# Copyright (C) 2020 Texas Instruments Incorporated +# Author: Peter Ujfalusi %YAML 1.2 --- $id: http://devicetree.org/schemas/dma/ti/k3-pktdma.yaml# @@ -7,7 +9,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: Texas Instruments K3 DMSS PKTDMA Device Tree Bindings maintainers: - - Peter Ujfalusi + - Peter Ujfalusi description: | The Packet DMA (PKTDMA) is intended to perform similar functions as the packet diff --git a/Documentation/devicetree/bindings/dma/ti/k3-udma.yaml b/Documentation/devicetree/bindings/dma/ti/k3-udma.yaml index 9a87fd9041eb..6a09bbf83d46 100644 --- a/Documentation/devicetree/bindings/dma/ti/k3-udma.yaml +++ b/Documentation/devicetree/bindings/dma/ti/k3-udma.yaml @@ -1,4 +1,6 @@ # SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +# Copyright (C) 2019 Texas Instruments Incorporated +# Author: Peter Ujfalusi %YAML 1.2 --- $id: http://devicetree.org/schemas/dma/ti/k3-udma.yaml# @@ -7,7 +9,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: Texas Instruments K3 NAVSS Unified DMA Device Tree Bindings maintainers: - - Peter Ujfalusi + - Peter Ujfalusi description: | The UDMA-P is intended to perform similar (but significantly upgraded) -- Peter Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
[PATCH 0/2] dmaengine: ti: Maintainer mail address change
Hi, My TI address is going to bounce after Friday (18.12.2020), switch my address to my private one for now. Regards, Peter --- Peter Ujfalusi (2): MAINTAINERS: Add entry for Texas Instruments DMA drivers dt-bindings: dma: ti: Update maintainer and author information .../devicetree/bindings/dma/ti/k3-bcdma.yaml| 4 +++- .../devicetree/bindings/dma/ti/k3-pktdma.yaml | 4 +++- .../devicetree/bindings/dma/ti/k3-udma.yaml | 4 +++- MAINTAINERS | 13 + 4 files changed, 22 insertions(+), 3 deletions(-) -- Peter Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
[PATCH 1/2] MAINTAINERS: Add entry for Texas Instruments DMA drivers
My employment with TI is coming to an end, it is my intention to look after the DMA drivers I have worked with over the years. Signed-off-by: Peter Ujfalusi Signed-off-by: Peter Ujfalusi --- MAINTAINERS | 13 + 1 file changed, 13 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 952731d1e43c..f6e7162241eb 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -17549,6 +17549,19 @@ S: Supported F: Documentation/devicetree/bindings/iio/dac/ti,dac7612.txt F: drivers/iio/dac/ti-dac7612.c +TEXAS INSTRUMENTS DMA DRIVERS +M: Peter Ujfalusi +L: dmaeng...@vger.kernel.org +S: Maintained +F: Documentation/devicetree/bindings/dma/ti-dma-crossbar.txt +F: Documentation/devicetree/bindings/dma/ti-edma.txt +F: Documentation/devicetree/bindings/dma/ti/ +F: drivers/dma/ti/ +X: drivers/dma/ti/cppi41.c +F: include/linux/dma/k3-udma-glue.h +F: include/linux/dma/ti-cppi5.h +F: include/linux/dma/k3-psil.h + TEXAS INSTRUMENTS' SYSTEM CONTROL INTERFACE (TISCI) PROTOCOL DRIVER M: Nishanth Menon M: Tero Kristo -- Peter Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
[PATCH 2/2] ASoC: dt-bindings: ti,j721e: Update maintainer and author information
My employment with TI is coming to an end, add the copyright and author comments as they due and change the maintainer mail address. Signed-off-by: Peter Ujfalusi Signed-off-by: Peter Ujfalusi --- .../devicetree/bindings/sound/ti,j721e-cpb-audio.yaml | 4 +++- .../devicetree/bindings/sound/ti,j721e-cpb-ivi-audio.yaml | 4 +++- 2 files changed, 6 insertions(+), 2 deletions(-) diff --git a/Documentation/devicetree/bindings/sound/ti,j721e-cpb-audio.yaml b/Documentation/devicetree/bindings/sound/ti,j721e-cpb-audio.yaml index 805da4d6a88e..ec06789b21df 100644 --- a/Documentation/devicetree/bindings/sound/ti,j721e-cpb-audio.yaml +++ b/Documentation/devicetree/bindings/sound/ti,j721e-cpb-audio.yaml @@ -1,4 +1,6 @@ # SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +# Copyright (C) 2020 Texas Instruments Incorporated +# Author: Peter Ujfalusi %YAML 1.2 --- $id: http://devicetree.org/schemas/sound/ti,j721e-cpb-audio.yaml# @@ -7,7 +9,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: Texas Instruments J721e Common Processor Board Audio Support maintainers: - - Peter Ujfalusi + - Peter Ujfalusi description: | The audio support on the board is using pcm3168a codec connected to McASP10 diff --git a/Documentation/devicetree/bindings/sound/ti,j721e-cpb-ivi-audio.yaml b/Documentation/devicetree/bindings/sound/ti,j721e-cpb-ivi-audio.yaml index bb780f621628..ee9f960de36b 100644 --- a/Documentation/devicetree/bindings/sound/ti,j721e-cpb-ivi-audio.yaml +++ b/Documentation/devicetree/bindings/sound/ti,j721e-cpb-ivi-audio.yaml @@ -1,4 +1,6 @@ # SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +# Copyright (C) 2020 Texas Instruments Incorporated +# Author: Peter Ujfalusi %YAML 1.2 --- $id: http://devicetree.org/schemas/sound/ti,j721e-cpb-ivi-audio.yaml# @@ -7,7 +9,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: Texas Instruments J721e Common Processor Board Audio Support maintainers: - - Peter Ujfalusi + - Peter Ujfalusi description: | The Infotainment board plugs into the Common Processor Board, the support of the -- Peter Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
Re: [PATCH 0/2] ASoC: ti: Maintainer mail address change
Hi, On 15/12/2020 15.05, Peter Ujfalusi wrote: > Hi, > > My TI address is going to bounce after Friday (18.12.2020), switch my email > address to my private one for now. Obviously I forgot to 'TO' the private myself... Doing that now. > > Regards, > Peter > --- > Peter Ujfalusi (2): > MAINTAINERS: Update email address for TI ASoC and twl4030 codec > drivers > ASoC: dt-bindings: ti,j721e: Update maintainer and author information > > .../devicetree/bindings/sound/ti,j721e-cpb-audio.yaml | 4 +++- > .../devicetree/bindings/sound/ti,j721e-cpb-ivi-audio.yaml | 4 +++- > MAINTAINERS | 6 +++--- > 3 files changed, 9 insertions(+), 5 deletions(-) > - Péter Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
[PATCH 1/2] MAINTAINERS: Update email address for TI ASoC and twl4030 codec drivers
My employment with TI is coming to an end, it is my intention to look after the drivers I have worked with over the years. Signed-off-by: Peter Ujfalusi Signed-off-by: Peter Ujfalusi --- MAINTAINERS | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index f6e7162241eb..a091f183b27f 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -12862,7 +12862,7 @@ F: include/misc/ocxl* F: include/uapi/misc/ocxl.h OMAP AUDIO SUPPORT -M: Peter Ujfalusi +M: Peter Ujfalusi M: Jarkko Nikula L: alsa-de...@alsa-project.org (moderated for non-subscribers) L: linux-o...@vger.kernel.org @@ -17537,7 +17537,7 @@ F: arch/xtensa/ F: drivers/irqchip/irq-xtensa-* TEXAS INSTRUMENTS ASoC DRIVERS -M: Peter Ujfalusi +M: Peter Ujfalusi L: alsa-de...@alsa-project.org (moderated for non-subscribers) S: Maintained F: sound/soc/ti/ @@ -17847,7 +17847,7 @@ F: Documentation/devicetree/bindings/net/nfc/trf7970a.txt F: drivers/nfc/trf7970a.c TI TWL4030 SERIES SOC CODEC DRIVER -M: Peter Ujfalusi +M: Peter Ujfalusi L: alsa-de...@alsa-project.org (moderated for non-subscribers) S: Maintained F: sound/soc/codecs/twl4030* -- Peter Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
[PATCH 0/2] ASoC: ti: Maintainer mail address change
Hi, My TI address is going to bounce after Friday (18.12.2020), switch my email address to my private one for now. Regards, Peter --- Peter Ujfalusi (2): MAINTAINERS: Update email address for TI ASoC and twl4030 codec drivers ASoC: dt-bindings: ti,j721e: Update maintainer and author information .../devicetree/bindings/sound/ti,j721e-cpb-audio.yaml | 4 +++- .../devicetree/bindings/sound/ti,j721e-cpb-ivi-audio.yaml | 4 +++- MAINTAINERS | 6 +++--- 3 files changed, 9 insertions(+), 5 deletions(-) -- Peter Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
[PATCH] dt-bindings: display: bridge: tc358768: Remove maintainer information
My employment with TI is coming to an end and I will not have access to the board where this bridge is connected to. It is better to remove a soon bouncing email address. Signed-off-by: Peter Ujfalusi --- .../devicetree/bindings/display/bridge/toshiba,tc358768.yaml | 3 --- 1 file changed, 3 deletions(-) diff --git a/Documentation/devicetree/bindings/display/bridge/toshiba,tc358768.yaml b/Documentation/devicetree/bindings/display/bridge/toshiba,tc358768.yaml index c036a75db8f7..454ab8032b97 100644 --- a/Documentation/devicetree/bindings/display/bridge/toshiba,tc358768.yaml +++ b/Documentation/devicetree/bindings/display/bridge/toshiba,tc358768.yaml @@ -6,9 +6,6 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: Toschiba TC358768/TC358778 Parallel RGB to MIPI DSI bridge -maintainers: - - Peter Ujfalusi - description: | The TC358768/TC358778 is bridge device which converts RGB to DSI. -- Peter Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
[PATCH 1/2] dmaengine: Extend the dmaengine_alignment for 128 and 256 bytes
Some DMA device can benefit with higher order of alignment than the maximum
of 64 bytes currently defined.
Define 128 and 256 bytes alignment for these devices.
Signed-off-by: Peter Ujfalusi
---
include/linux/dmaengine.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/include/linux/dmaengine.h b/include/linux/dmaengine.h
index 68130f5f599e..004736b6a9c8 100644
--- a/include/linux/dmaengine.h
+++ b/include/linux/dmaengine.h
@@ -745,6 +745,8 @@ enum dmaengine_alignment {
DMAENGINE_ALIGN_16_BYTES = 4,
DMAENGINE_ALIGN_32_BYTES = 5,
DMAENGINE_ALIGN_64_BYTES = 6,
+ DMAENGINE_ALIGN_128_BYTES = 7,
+ DMAENGINE_ALIGN_256_BYTES = 8,
};
/**
--
Peter
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
[PATCH 2/2] dmaengine: ti: k3-udma: Add support for burst_size configuration for mem2mem
The UDMA and BCDMA can provide higher throughput if the burst_size of the
channel is changed from it's default (which is 64 bytes) for Ultra-high
and high capacity channels.
This performance benefit is even more visible when the buffers are aligned
with the burst_size configuration.
The am654 does not have a way to change the burst size, but it is using
64 bytes burst, so increasing the copy_align from 8 bytes to 64 (and
clients taking that into account) can increase the throughput as well.
Numbers gathered on j721e:
echo 800 > /sys/module/dmatest/parameters/test_buf_size
echo 2000 > /sys/module/dmatest/parameters/timeout
echo 50 > /sys/module/dmatest/parameters/iterations
echo 1 > /sys/module/dmatest/parameters/max_channels
Prior this patch: ~1.3 GB/s
After this patch: ~1.8 GB/s
with 1 byte alignment: ~1.7 GB/s
Signed-off-by: Peter Ujfalusi
---
drivers/dma/ti/k3-udma.c | 115 +--
1 file changed, 110 insertions(+), 5 deletions(-)
diff --git a/drivers/dma/ti/k3-udma.c b/drivers/dma/ti/k3-udma.c
index 87157cbae1b8..54e4ccb1b37e 100644
--- a/drivers/dma/ti/k3-udma.c
+++ b/drivers/dma/ti/k3-udma.c
@@ -121,6 +121,11 @@ struct udma_oes_offsets {
#define UDMA_FLAG_PDMA_ACC32 BIT(0)
#define UDMA_FLAG_PDMA_BURST BIT(1)
#define UDMA_FLAG_TDTYPE BIT(2)
+#define UDMA_FLAG_BURST_SIZE BIT(3)
+#define UDMA_FLAGS_J7_CLASS(UDMA_FLAG_PDMA_ACC32 | \
+UDMA_FLAG_PDMA_BURST | \
+UDMA_FLAG_TDTYPE | \
+UDMA_FLAG_BURST_SIZE)
struct udma_match_data {
enum k3_dma_type type;
@@ -128,6 +133,7 @@ struct udma_match_data {
bool enable_memcpy_support;
u32 flags;
u32 statictr_z_mask;
+ u8 burst_size[3];
};
struct udma_soc_data {
@@ -436,6 +442,18 @@ static void k3_configure_chan_coherency(struct dma_chan
*chan, u32 asel)
}
}
+static u8 udma_get_chan_tpl_index(struct udma_tpl *tpl_map, int chan_id)
+{
+ int i;
+
+ for (i = 0; i < tpl_map->levels; i++) {
+ if (chan_id >= tpl_map->start_idx[i])
+ return i;
+ }
+
+ return 0;
+}
+
static void udma_reset_uchan(struct udma_chan *uc)
{
memset(>config, 0, sizeof(uc->config));
@@ -1811,6 +1829,7 @@ static int udma_tisci_m2m_channel_config(struct udma_chan
*uc)
const struct ti_sci_rm_udmap_ops *tisci_ops = tisci_rm->tisci_udmap_ops;
struct udma_tchan *tchan = uc->tchan;
struct udma_rchan *rchan = uc->rchan;
+ u8 burst_size = 0;
int ret = 0;
/* Non synchronized - mem to mem type of transfer */
@@ -1818,6 +1837,12 @@ static int udma_tisci_m2m_channel_config(struct
udma_chan *uc)
struct ti_sci_msg_rm_udmap_tx_ch_cfg req_tx = { 0 };
struct ti_sci_msg_rm_udmap_rx_ch_cfg req_rx = { 0 };
+ if (ud->match_data->flags & UDMA_FLAG_BURST_SIZE) {
+ u8 tpl = udma_get_chan_tpl_index(>tchan_tpl, tchan->id);
+
+ burst_size = ud->match_data->burst_size[tpl];
+ }
+
req_tx.valid_params = TISCI_UDMA_TCHAN_VALID_PARAMS;
req_tx.nav_id = tisci_rm->tisci_dev_id;
req_tx.index = tchan->id;
@@ -1825,6 +1850,10 @@ static int udma_tisci_m2m_channel_config(struct
udma_chan *uc)
req_tx.tx_fetch_size = sizeof(struct cppi5_desc_hdr_t) >> 2;
req_tx.txcq_qnum = tc_ring;
req_tx.tx_atype = ud->atype;
+ if (burst_size) {
+ req_tx.valid_params |=
TI_SCI_MSG_VALUE_RM_UDMAP_CH_BURST_SIZE_VALID;
+ req_tx.tx_burst_size = burst_size;
+ }
ret = tisci_ops->tx_ch_cfg(tisci_rm->tisci, _tx);
if (ret) {
@@ -1839,6 +1868,10 @@ static int udma_tisci_m2m_channel_config(struct
udma_chan *uc)
req_rx.rxcq_qnum = tc_ring;
req_rx.rx_chan_type = TI_SCI_RM_UDMAP_CHAN_TYPE_3RDP_BCOPY_PBRR;
req_rx.rx_atype = ud->atype;
+ if (burst_size) {
+ req_rx.valid_params |=
TI_SCI_MSG_VALUE_RM_UDMAP_CH_BURST_SIZE_VALID;
+ req_rx.rx_burst_size = burst_size;
+ }
ret = tisci_ops->rx_ch_cfg(tisci_rm->tisci, _rx);
if (ret)
@@ -1854,12 +1887,23 @@ static int bcdma_tisci_m2m_channel_config(struct
udma_chan *uc)
const struct ti_sci_rm_udmap_ops *tisci_ops = tisci_rm->tisci_udmap_ops;
struct ti_sci_msg_rm_udmap_tx_ch_cfg req_tx = { 0 };
struct udma_bchan *bchan = uc->bchan;
+ u8 burst_size = 0;
int ret = 0;
+ if (ud->match_data->flags & UDMA_FLAG_BURST_SIZE) {
+ u8 tpl = udma_get_chan_tpl_index(>bchan_tpl, bchan->id);
+
+ burst_size = ud->match_data->burst_size[tpl];
+ }
+
req_tx.valid_p
[PATCH 0/2] dmaengine: ti: k3-udma: memcpy throughput improvement
Hi, Newer members of the KS3 family (after AM654) have support for burst_size configuration for each DMA channel. The HW default value is 64 bytes but on higher throughput channels it can be increased to 256 bytes (UCHANs) or 128 byes (HCHANs). Aligning the buffers and length of the transfer to the burst size also increases the throughput. Numbers gathered on j721e (UCHAN pair): echo 800 > /sys/module/dmatest/parameters/test_buf_size echo 2000 > /sys/module/dmatest/parameters/timeout echo 50 > /sys/module/dmatest/parameters/iterations echo 1 > /sys/module/dmatest/parameters/max_channels Prior to this patch: ~1.3 GB/s After this patch: ~1.8 GB/s with 1 byte alignment: ~1.7 GB/s The patches are on top of the AM64 support series: https://lore.kernel.org/lkml/20201208090440.31792-1-peter.ujfal...@ti.com/ Regards, Peter --- Peter Ujfalusi (2): dmaengine: Extend the dmaengine_alignment for 128 and 256 bytes dmaengine: ti: k3-udma: Add support for burst_size configuration for mem2mem drivers/dma/ti/k3-udma.c | 115 -- include/linux/dmaengine.h | 2 + 2 files changed, 112 insertions(+), 5 deletions(-) -- Peter Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
[PATCH] soc: ti: k3-ringacc: Use correct error casting in k3_ringacc_dmarings_init
Use ERR_CAST() when devm_ioremap_resource() fails. Reported-by: kernel test robot Signed-off-by: Peter Ujfalusi --- Hi Vinod, it came to my attention too late. This patch fixes the sparse warnig introduced by the AM64 support in https://lore.kernel.org/lkml/20201208090440.31792-1-peter.ujfal...@ti.com/ Regards, Peter drivers/soc/ti/k3-ringacc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/soc/ti/k3-ringacc.c b/drivers/soc/ti/k3-ringacc.c index c88c305ba367..b495b0d5d0fa 100644 --- a/drivers/soc/ti/k3-ringacc.c +++ b/drivers/soc/ti/k3-ringacc.c @@ -1476,7 +1476,7 @@ struct k3_ringacc *k3_ringacc_dmarings_init(struct platform_device *pdev, res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "ringrt"); base_rt = devm_ioremap_resource(dev, res); if (IS_ERR(base_rt)) - return base_rt; + return ERR_CAST(base_rt); ringacc->rings = devm_kzalloc(dev, sizeof(*ringacc->rings) * -- Peter Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
Re: [PATCH v3 00/20] dmaengine/soc: k3-udma: Add support for BCDMA and PKTDMA
Hi Vinod, On 11/12/2020 18.24, Vinod Koul wrote: > On 08-12-20, 11:04, Peter Ujfalusi wrote: >> Hi, >> >> The series have build dependency on ti_sci/soc series (v2): >> https://lore.kernel.org/lkml/20201008115224.1591-1-peter.ujfal...@ti.com/ >> >> Santosh kindly provided immutable branch and tag holding the series: >> git://git.kernel.org/pub/scm/linux/kernel/git/ssantosh/linux-keystone.git >> tags/drivers_soc_for_5.11 > > I have picked this and then merged this and pushed to test branch. If > everything is okay, it will be next on monday Thank you! this might cause a sparse warning: https://lore.kernel.org/lkml/a1f83b16-c1ce-630e-3410-738b80a92...@ti.com/ I can send an incremental patch or resend the whole series with this correction? - Péter Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
Re: [PATCH v3 16/20] soc: ti: k3-ringacc: add AM64 DMA rings support.
On 08/12/2020 11.04, Peter Ujfalusi wrote:
> From: Grygorii Strashko
>
> The DMAs in AM64 have built in rings compared to AM654/J721e/J7200 where a
> separate and generic ringacc is used.
>
> The ring SW interface is similar to ringacc with some major architectural
> differences, like
>
> They are part of the DMA (BCDMA or PKTDMA).
>
> They are dual mode rings are modeled as pair of Rings objects which has
> common configuration and memory buffer, but separate real-time control
> register sets for each direction mem2dev (forward) and dev2mem (reverse).
>
> The ringacc driver must be initialized for DMA rings use with
> k3_ringacc_dmarings_init() as it is not an independent device as ringacc
> is.
>
> AM64 rings must be requested only using k3_ringacc_request_rings_pair(),
> and forward ring must always be initialized/configured. After this any
> other Ringacc APIs can be used without any callers changes.
>
> Signed-off-by: Grygorii Strashko
> Signed-off-by: Peter Ujfalusi
> ---
> drivers/soc/ti/k3-ringacc.c | 325 +-
> include/linux/soc/ti/k3-ringacc.h | 17 ++
> 2 files changed, 335 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/soc/ti/k3-ringacc.c b/drivers/soc/ti/k3-ringacc.c
> index 119164abcb41..c88c305ba367 100644
> --- a/drivers/soc/ti/k3-ringacc.c
> +++ b/drivers/soc/ti/k3-ringacc.c
...
> +struct k3_ringacc *k3_ringacc_dmarings_init(struct platform_device *pdev,
> + struct k3_ringacc_init_data *data)
> +{
> + struct device *dev = >dev;
> + struct k3_ringacc *ringacc;
> + void __iomem *base_rt;
> + struct resource *res;
> + int i;
> +
> + ringacc = devm_kzalloc(dev, sizeof(*ringacc), GFP_KERNEL);
> + if (!ringacc)
> + return ERR_PTR(-ENOMEM);
> +
> + ringacc->dev = dev;
> + ringacc->dma_rings = true;
> + ringacc->num_rings = data->num_rings;
> + ringacc->tisci = data->tisci;
> + ringacc->tisci_dev_id = data->tisci_dev_id;
> +
> + mutex_init(>req_lock);
> +
> + res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "ringrt");
> + base_rt = devm_ioremap_resource(dev, res);
> + if (IS_ERR(base_rt))
> + return base_rt;
this must have been:
return ERR_CAST(base_rt);
> +
> + ringacc->rings = devm_kzalloc(dev,
> + sizeof(*ringacc->rings) *
> + ringacc->num_rings * 2,
> + GFP_KERNEL);
> + ringacc->rings_inuse = devm_kcalloc(dev,
> + BITS_TO_LONGS(ringacc->num_rings),
> + sizeof(unsigned long), GFP_KERNEL);
> +
> + if (!ringacc->rings || !ringacc->rings_inuse)
> + return ERR_PTR(-ENOMEM);
> +
> + for (i = 0; i < ringacc->num_rings; i++) {
> + struct k3_ring *ring = >rings[i];
> +
> + ring->rt = base_rt + K3_DMARING_RT_REGS_STEP * i;
> + ring->parent = ringacc;
> + ring->ring_id = i;
> + ring->proxy_id = K3_RINGACC_PROXY_NOT_USED;
> +
> + ring = >rings[ringacc->num_rings + i];
> + ring->rt = base_rt + K3_DMARING_RT_REGS_STEP * i +
> +K3_DMARING_RT_REGS_REVERSE_OFS;
> + ring->parent = ringacc;
> + ring->ring_id = i;
> + ring->proxy_id = K3_RINGACC_PROXY_NOT_USED;
> + ring->flags = K3_RING_FLAG_REVERSE;
> + }
> +
> + ringacc->tisci_ring_ops = >tisci->ops.rm_ring_ops;
> +
> + dev_info(dev, "Number of rings: %u\n", ringacc->num_rings);
> +
> + return ringacc;
> +}
- Péter
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
[PATCH v3 00/20] dmaengine/soc: k3-udma: Add support for BCDMA and PKTDMA
Hi, The series have build dependency on ti_sci/soc series (v2): https://lore.kernel.org/lkml/20201008115224.1591-1-peter.ujfal...@ti.com/ Santosh kindly provided immutable branch and tag holding the series: git://git.kernel.org/pub/scm/linux/kernel/git/ssantosh/linux-keystone.git tags/drivers_soc_for_5.11 The unmapped event handling in INTA is already mainline. Changes since v2: - Schema files: - Moved compatible as first property and use const instead of enum for now - Removed #address-cells and #size-cells - am64 PSI-L thread map updated to include all threads as the SoC is public now - glue layer - get the ringacc pointer from udma_dev instead of using OF based lookup - Correct fdq ring ID for rx channel configuration - Fix the glue channel dev setup by adding a new classm but with empty remove callback Changes since v1: - Both DT binding document has been updated to address all comments and suggestions from Rob, all checks are passing on them - included new patch to fix the normal channel start offset when ultra-high capacity channels are available for the UDMA and updated the BCDMA/PKTDMA patches along the same line - Re-arranged the patches for Vinod so that the preparational patches and fixes can be picked up separately (they still have dependency on Santosh's branch): patch 1-5: Fixes and new features for existing devices using UDMA, but the the BCDMA/PKTDMA support is building on top of these. Build dependency on Santosh's branch patch 6: Optional second stage router configuration callback support in core patch 7-9: Per channel coherency support in core and use it in dmatest. patch 10-: Initial AM64 BCDMA and PKTDMA support The DMSS introduced within AM64 as a simplified Data movement engine is built on similar grounds as the K3 NAVSS and UDMAP, but with significant architectural changes. - Rings are built into the DMAs The DMAs no longer use the general purpose ringacc, all rings has been moved inside of the DMAs. The new rings within the DMAs are simplified to be dual directional compared to the uni-directional rings in ringacc. There is no more of a concept of generic purpose rings, all rings are assigned to specific channels or flows. - Per channel coherency support The DMAs use the 'ASEL' bits to select data and configuration fetch path. The ASEL bits are placed at the unused parts of any address field used by the DMAs (pointers to descriptors, addresses in descriptors, ring base addresses). The ASEL is not part of the address (the DMAs can address 48bits). Individual channels can be configured to be coherent (via ACP port) or non coherent individually by configuring the ASEL to appropriate value. - Two different DMAs (well, three actually) PKTDMA Similar to UDMAP channels configured in packet mode. The flow configuration of the channels has changed significantly in a way that each channel have at least one flow assigned at design time and each flow is directly mapped to corresponding ring. When multiple flows are set, the channel can only use the flows within it's assigned range. PKTDMA also introduced multiple tflows which did not existed in UDMAP. BCDMA It has two types of channels: - split channels (tchan/rchan): Similar to UDMAP channels configured in TR mode. - Block copy channels (bchan): Similar to EDMA or traditional DMA channels, they can be used for mem2mem type of transfers or to service peripherals not accessible via PSI-L by using external triggers for the TR. BCDMA channels do not have support for multiple flows With the introduction of the new DMAs (especially the BCDMA) we also need to update the resource manager code to support the second range from sysfw for UDMA channels. The two outstanding change in the series in my view is the handling of the DMAs sideband signal of ASEL to select path to provide coherency or non coherency. The smaller one is the device_router_config callback to allow the configuration of the triggers when BCDMA is servicing a triggering peripheral to solve a chicken-egg situation: The router needs to know the event number to send which in turn depends on the channel we got for servicing the peripheral. Regards, Peter --- Grygorii Strashko (1): soc: ti: k3-ringacc: add AM64 DMA rings support. Peter Ujfalusi (18): dmaengine: ti: k3-udma: Correct normal channel offset when uchan_cnt is not 0 dmaengine: ti: k3-udma: Wait for peer teardown completion if supported dmaengine: ti: k3-udma: Add support for second resource range from sysfw dmaengine: ti: k3-udma-glue: Add function to get device pointer for DMA API dmaengine: ti: k3-udma-glue: Get the ringacc from udma_dev dmaengine: ti: k3-udma-glue: Configure the dma_dev for rings dmaengine: of-dma: Add support for optional router configuration callback dmaengine: Add support for per channel coherency handling dmaengine: doc: client: Update for dmaengine_get_dma_device() usage dmaengine: dmatest: Use
[PATCH v3 14/20] dmaengine: ti: k3-psil: Add initial map for AM64
Add initial PSI-L map file for AM64.
Signed-off-by: Peter Ujfalusi
---
drivers/dma/ti/Makefile | 3 +-
drivers/dma/ti/k3-psil-am64.c | 158 ++
drivers/dma/ti/k3-psil-priv.h | 1 +
drivers/dma/ti/k3-psil.c | 1 +
4 files changed, 162 insertions(+), 1 deletion(-)
create mode 100644 drivers/dma/ti/k3-psil-am64.c
diff --git a/drivers/dma/ti/Makefile b/drivers/dma/ti/Makefile
index 0c67254caee6..bd496efadff7 100644
--- a/drivers/dma/ti/Makefile
+++ b/drivers/dma/ti/Makefile
@@ -7,5 +7,6 @@ obj-$(CONFIG_TI_K3_UDMA_GLUE_LAYER) += k3-udma-glue.o
obj-$(CONFIG_TI_K3_PSIL) += k3-psil.o \
k3-psil-am654.o \
k3-psil-j721e.o \
- k3-psil-j7200.o
+ k3-psil-j7200.o \
+ k3-psil-am64.o
obj-$(CONFIG_TI_DMA_CROSSBAR) += dma-crossbar.o
diff --git a/drivers/dma/ti/k3-psil-am64.c b/drivers/dma/ti/k3-psil-am64.c
new file mode 100644
index ..9fdeaa11a4fc
--- /dev/null
+++ b/drivers/dma/ti/k3-psil-am64.c
@@ -0,0 +1,158 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2020 Texas Instruments Incorporated - https://www.ti.com
+ * Author: Peter Ujfalusi
+ */
+
+#include
+
+#include "k3-psil-priv.h"
+
+#define PSIL_PDMA_XY_TR(x) \
+ { \
+ .thread_id = x, \
+ .ep_config = { \
+ .ep_type = PSIL_EP_PDMA_XY, \
+ .mapped_channel_id = -1,\
+ .default_flow_id = -1, \
+ }, \
+ }
+
+#define PSIL_PDMA_XY_PKT(x)\
+ { \
+ .thread_id = x, \
+ .ep_config = { \
+ .ep_type = PSIL_EP_PDMA_XY, \
+ .mapped_channel_id = -1,\
+ .default_flow_id = -1, \
+ .pkt_mode = 1, \
+ }, \
+ }
+
+#define PSIL_ETHERNET(x, ch, flow_base, flow_cnt) \
+ { \
+ .thread_id = x, \
+ .ep_config = { \
+ .ep_type = PSIL_EP_NATIVE, \
+ .pkt_mode = 1, \
+ .needs_epib = 1,\
+ .psd_size = 16, \
+ .mapped_channel_id = ch,\
+ .flow_start = flow_base,\
+ .flow_num = flow_cnt, \
+ .default_flow_id = flow_base, \
+ }, \
+ }
+
+#define PSIL_SAUL(x, ch, flow_base, flow_cnt, default_flow, tx)\
+ { \
+ .thread_id = x, \
+ .ep_config = { \
+ .ep_type = PSIL_EP_NATIVE, \
+ .pkt_mode = 1, \
+ .needs_epib = 1,\
+ .psd_size = 64, \
+ .mapped_channel_id = ch,\
+ .flow_start = flow_base,\
+ .flow_num = flow_cnt, \
+ .default_flow_id = default_flow,\
+ .notdpkt = tx, \
+ }, \
+ }
+
+/* PSI-L source thread IDs, used for RX (DMA_DEV_TO_MEM) */
+static struct psil_ep am64_src_ep_map[] = {
+ /* SAUL */
+ PSIL_SAUL(0x4000, 17, 32, 8, 32, 0),
+ PSIL_SAUL(0x4001, 18, 32, 8, 33, 0),
+ PSIL_SAUL(0x4002, 19, 40, 8, 40, 0),
+ PSIL_SAUL(0x4003, 20, 40, 8, 41, 0),
+ /* ICSS_G0 */
+ PSIL_ETHERNET(0x4100, 21, 48, 16),
+ PSIL_ETHERNET(0x4101, 22, 64, 16),
+ PSIL_ETHERNET(0x4102, 23, 80, 16),
+ PSIL_ETHERNET(0x4103, 24, 96, 16),
+ /* ICSS_G1 */
+ PSIL_ETHERNET(0x4200, 25, 112, 16),
+ PSIL_ETHERNET(0x4201, 26, 128, 16),
+ PSIL_ETHERNET(0x4202, 27, 144, 16),
+ PSIL_ETHERNET(0x4203, 28, 160, 16),
+ /* PDMA_MAIN
[PATCH v3 09/20] dmaengine: doc: client: Update for dmaengine_get_dma_device() usage
Client drivers should use the dmaengine_get_dma_device(chan) to get the device pointer which should be used for DMA API for allocations and mapping. Signed-off-by: Peter Ujfalusi --- Documentation/driver-api/dmaengine/client.rst | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/Documentation/driver-api/dmaengine/client.rst b/Documentation/driver-api/dmaengine/client.rst index 09a3f66dcd26..bfd057b21a00 100644 --- a/Documentation/driver-api/dmaengine/client.rst +++ b/Documentation/driver-api/dmaengine/client.rst @@ -120,7 +120,9 @@ The details of these operations are: .. code-block:: c - nr_sg = dma_map_sg(chan->device->dev, sgl, sg_len); + struct device *dma_dev = dmaengine_get_dma_device(chan); + + nr_sg = dma_map_sg(dma_dev, sgl, sg_len); if (nr_sg == 0) /* error */ -- Peter Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
[PATCH v3 13/20] dmaengine: ti: k3-psil: Extend psil_endpoint_config for K3 PKTDMA
Additional fields needed for K3 PKTDMA to be able to handle the mapped
channels (channels are locked to handle specific threads) and flow ranges
for these mapped threads.
PKTDMA also introduces tflow for tx channels which can not be found in
K3 UDMA architecture.
Signed-off-by: Peter Ujfalusi
---
include/linux/dma/k3-psil.h | 16
1 file changed, 16 insertions(+)
diff --git a/include/linux/dma/k3-psil.h b/include/linux/dma/k3-psil.h
index 1962f75fa2d3..36e22c5a0f29 100644
--- a/include/linux/dma/k3-psil.h
+++ b/include/linux/dma/k3-psil.h
@@ -50,6 +50,15 @@ enum psil_endpoint_type {
* @channel_tpl: Desired throughput level for the channel
* @pdma_acc32:ACC32 must be enabled on the PDMA side
* @pdma_burst:BURST must be enabled on the PDMA side
+ * @mapped_channel_id: PKTDMA thread to channel mapping for mapped channels.
+ * The thread must be serviced by the specified channel if
+ * mapped_channel_id is >= 0 in case of PKTDMA
+ * @flow_start:PKDMA flow range start of mapped channel.
Unmapped
+ * channels use flow_id == chan_id
+ * @flow_num: PKDMA flow count of mapped channel. Unmapped channels
+ * use flow_id == chan_id
+ * @default_flow_id: PKDMA default (r)flow index of mapped channel.
+ * Must be within the flow range of the mapped channel.
*/
struct psil_endpoint_config {
enum psil_endpoint_type ep_type;
@@ -63,6 +72,13 @@ struct psil_endpoint_config {
/* PDMA properties, valid for PSIL_EP_PDMA_* */
unsigned pdma_acc32:1;
unsigned pdma_burst:1;
+
+ /* PKDMA mapped channel */
+ int mapped_channel_id;
+ /* PKTDMA tflow and rflow ranges for mapped channel */
+ u16 flow_start;
+ u16 flow_num;
+ u16 default_flow_id;
};
int psil_set_new_ep_config(struct device *dev, const char *name,
--
Peter
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
[PATCH v3 19/20] dmaengine: ti: k3-udma: Initial support for K3 PKTDMA
One of the DMAs introduced with AM64 is the Packet DMA (PKTDMA).
It serves similar purpose as K3 UDMAP channels in packet mode, but with
notable differences, like tflow support and channels being allocated to
service specific peripherals.
The rings for the PKTDMA is integrated within the DMA itself instead of
using rings from the general purpose ringacc.
PKTDMA can be used to service PSI-L peripherals, similarly to
K3 UDMA channels.
Most of the driver code can be reused for PKTDMA tchan/rchan support but
new setup and allocation functions are needed to handle the differences
between the DMAs.
Signed-off-by: Peter Ujfalusi
---
drivers/dma/ti/k3-udma-private.c | 9 +
drivers/dma/ti/k3-udma.c | 545 +--
drivers/dma/ti/k3-udma.h | 4 +
3 files changed, 533 insertions(+), 25 deletions(-)
diff --git a/drivers/dma/ti/k3-udma-private.c b/drivers/dma/ti/k3-udma-private.c
index 0856721d0b04..b8567dace644 100644
--- a/drivers/dma/ti/k3-udma-private.c
+++ b/drivers/dma/ti/k3-udma-private.c
@@ -88,6 +88,9 @@ EXPORT_SYMBOL(xudma_free_gp_rflow_range);
bool xudma_rflow_is_gp(struct udma_dev *ud, int id)
{
+ if (!ud->rflow_gp_map)
+ return false;
+
return !test_bit(id, ud->rflow_gp_map);
}
EXPORT_SYMBOL(xudma_rflow_is_gp);
@@ -119,6 +122,12 @@ void xudma_rflow_put(struct udma_dev *ud, struct
udma_rflow *p)
}
EXPORT_SYMBOL(xudma_rflow_put);
+int xudma_get_rflow_ring_offset(struct udma_dev *ud)
+{
+ return ud->tflow_cnt;
+}
+EXPORT_SYMBOL(xudma_get_rflow_ring_offset);
+
#define XUDMA_GET_RESOURCE_ID(res) \
int xudma_##res##_get_id(struct udma_##res *p) \
{ \
diff --git a/drivers/dma/ti/k3-udma.c b/drivers/dma/ti/k3-udma.c
index 0dc3430fea40..87157cbae1b8 100644
--- a/drivers/dma/ti/k3-udma.c
+++ b/drivers/dma/ti/k3-udma.c
@@ -59,6 +59,7 @@ struct udma_chan;
enum k3_dma_type {
DMA_TYPE_UDMA = 0,
DMA_TYPE_BCDMA,
+ DMA_TYPE_PKTDMA,
};
enum udma_mmr {
@@ -82,6 +83,8 @@ struct udma_tchan {
int id;
struct k3_ring *t_ring; /* Transmit ring */
struct k3_ring *tc_ring; /* Transmit Completion ring */
+ int tflow_id; /* applicable only for PKTDMA */
+
};
#define udma_bchan udma_tchan
@@ -109,6 +112,10 @@ struct udma_oes_offsets {
u32 bcdma_tchan_ring;
u32 bcdma_rchan_data;
u32 bcdma_rchan_ring;
+
+ /* PKTDMA Output Event Offsets */
+ u32 pktdma_tchan_flow;
+ u32 pktdma_rchan_flow;
};
#define UDMA_FLAG_PDMA_ACC32 BIT(0)
@@ -179,12 +186,14 @@ struct udma_dev {
int echan_cnt;
int rchan_cnt;
int rflow_cnt;
+ int tflow_cnt;
unsigned long *bchan_map;
unsigned long *tchan_map;
unsigned long *rchan_map;
unsigned long *rflow_gp_map;
unsigned long *rflow_gp_map_allocated;
unsigned long *rflow_in_use;
+ unsigned long *tflow_map;
struct udma_bchan *bchans;
struct udma_tchan *tchans;
@@ -249,6 +258,11 @@ struct udma_chan_config {
u32 tr_trigger_type;
+ /* PKDMA mapped channel */
+ int mapped_channel_id;
+ /* PKTDMA default tflow or rflow for mapped channel */
+ int default_flow_id;
+
enum dma_transfer_direction dir;
};
@@ -426,6 +440,8 @@ static void udma_reset_uchan(struct udma_chan *uc)
{
memset(>config, 0, sizeof(uc->config));
uc->config.remote_thread_id = -1;
+ uc->config.mapped_channel_id = -1;
+ uc->config.default_flow_id = -1;
uc->state = UDMA_CHAN_IS_IDLE;
}
@@ -815,10 +831,16 @@ static void udma_start_desc(struct udma_chan *uc)
{
struct udma_chan_config *ucc = >config;
- if (ucc->pkt_mode && (uc->cyclic || ucc->dir == DMA_DEV_TO_MEM)) {
+ if (uc->ud->match_data->type == DMA_TYPE_UDMA && ucc->pkt_mode &&
+ (uc->cyclic || ucc->dir == DMA_DEV_TO_MEM)) {
int i;
- /* Push all descriptors to ring for packet mode cyclic or RX */
+ /*
+* UDMA only: Push all descriptors to ring for packet mode
+* cyclic or RX
+* PKTDMA supports pre-linked descriptor and cyclic is not
+* supported
+*/
for (i = 0; i < uc->desc->sglen; i++)
udma_push_to_ring(uc, i);
} else {
@@ -1248,10 +1270,12 @@ static struct udma_rflow *__udma_get_rflow(struct
udma_dev *ud, int id)
if (test_bit(id, ud->rflow_in_use))
return ERR_PTR(-ENOENT);
- /* GP rflow has to be allocated first */
- if (!test_bit(id, ud->rflow_gp_map) &&
- !test_bit(id, ud->rflow_gp_map_allocated))
- ret
[PATCH v3 11/20] dt-bindings: dma: ti: Add document for K3 BCDMA
New binding document for
Texas Instruments K3 Block Copy DMA (BCDMA).
BCDMA is introduced as part of AM64.
Signed-off-by: Peter Ujfalusi
---
.../devicetree/bindings/dma/ti/k3-bcdma.yaml | 164 ++
1 file changed, 164 insertions(+)
create mode 100644 Documentation/devicetree/bindings/dma/ti/k3-bcdma.yaml
diff --git a/Documentation/devicetree/bindings/dma/ti/k3-bcdma.yaml
b/Documentation/devicetree/bindings/dma/ti/k3-bcdma.yaml
new file mode 100644
index ..b15f68c499cb
--- /dev/null
+++ b/Documentation/devicetree/bindings/dma/ti/k3-bcdma.yaml
@@ -0,0 +1,164 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/dma/ti/k3-bcdma.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Texas Instruments K3 DMSS BCDMA Device Tree Bindings
+
+maintainers:
+ - Peter Ujfalusi
+
+description: |
+ The Block Copy DMA (BCDMA) is intended to perform similar functions as the TR
+ mode channels of K3 UDMA-P.
+ BCDMA includes block copy channels and Split channels.
+
+ Block copy channels mainly used for memory to memory transfers, but with
+ optional triggers a block copy channel can service peripherals by accessing
+ directly to memory mapped registers or area.
+
+ Split channels can be used to service PSI-L based peripherals.
+ The peripherals can be PSI-L native or legacy, non PSI-L native peripherals
+ with PDMAs. PDMA is tasked to act as a bridge between the PSI-L fabric and
the
+ legacy peripheral.
+
+ PDMAs can be configured via BCDMA split channel's peer registers to match
with
+ the configuration of the legacy peripheral.
+
+allOf:
+ - $ref: /schemas/dma/dma-controller.yaml#
+
+properties:
+ compatible:
+const: ti,am64-dmss-bcdma
+
+ "#dma-cells":
+const: 3
+description: |
+ cell 1: type of the BCDMA channel to be used to service the peripheral:
+0 - split channel
+1 - block copy channel using global trigger 1
+2 - block copy channel using global trigger 2
+3 - block copy channel using local trigger
+
+ cell 2: parameter for the channel:
+if cell 1 is 0 (split channel):
+ PSI-L thread ID of the remote (to BCDMA) end.
+ Valid ranges for thread ID depends on the data movement direction:
+ for source thread IDs (rx): 0 - 0x7fff
+ for destination thread IDs (tx): 0x8000 - 0x
+
+ Please refer to the device documentation for the PSI-L thread map and
+ also the PSI-L peripheral chapter for the correct thread ID.
+if cell 1 is 1 or 2 (block copy channel using global trigger):
+ Unused, ignored
+
+ The trigger must be configured for the channel externally to BCDMA,
+ channels using global triggers should not be requested directly, but
+ via DMA event router.
+if cell 1 is 3 (block copy channel using local trigger):
+ bchan number of the locally triggered channel
+
+ cell 3: ASEL value for the channel
+
+ reg:
+maxItems: 5
+
+ reg-names:
+items:
+ - const: gcfg
+ - const: bchanrt
+ - const: rchanrt
+ - const: tchanrt
+ - const: ringrt
+
+ msi-parent: true
+
+ ti,asel:
+$ref: /schemas/types.yaml#/definitions/uint32
+description: ASEL value for non slave channels
+
+ ti,sci-rm-range-bchan:
+$ref: /schemas/types.yaml#/definitions/uint32-array
+description: |
+ Array of BCDMA block-copy channel resource subtypes for resource
+ allocation for this host
+minItems: 1
+# Should be enough
+maxItems: 255
+items:
+ maximum: 0x3f
+
+ ti,sci-rm-range-tchan:
+$ref: /schemas/types.yaml#/definitions/uint32-array
+description: |
+ Array of BCDMA split tx channel resource subtypes for resource allocation
+ for this host
+minItems: 1
+# Should be enough
+maxItems: 255
+items:
+ maximum: 0x3f
+
+ ti,sci-rm-range-rchan:
+$ref: /schemas/types.yaml#/definitions/uint32-array
+description: |
+ Array of BCDMA split rx channel resource subtypes for resource allocation
+ for this host
+minItems: 1
+# Should be enough
+maxItems: 255
+items:
+ maximum: 0x3f
+
+required:
+ - compatible
+ - "#dma-cells"
+ - reg
+ - reg-names
+ - msi-parent
+ - ti,sci
+ - ti,sci-dev-id
+ - ti,sci-rm-range-bchan
+ - ti,sci-rm-range-tchan
+ - ti,sci-rm-range-rchan
+
+unevaluatedProperties: false
+
+examples:
+ - |+
+cbass_main {
+#address-cells = <2>;
+#size-cells = <2>;
+
+main_dmss {
+compatible = "simple-mfd";
+#address-cells = <2>;
+#size-cells = <2>;
+dma-ranges;
+ranges;
+
+ti,sci-dev-id = <25>;
+
+main_bcdma: dma-controller@485c0100 {
+compatible = "ti,am64-dmss-bcdma";
+
+re
[PATCH v3 18/20] dmaengine: ti: k3-udma: Add support for BCDMA channel TPL handling
Unlike UDMAP the BCDMA defines the channel TPL levels per channel type.
In UDMAP the number of high and ultra-high channels applies to both tchan
and rchan.
BCDMA defines the TPL per channel types: bchan, tchan and rchan can have
different number of high and ultra-high channels.
In order to support BCDMA channel TPL we need to move the tpl information
as per channel type property for the DMAs.
Signed-off-by: Peter Ujfalusi
---
drivers/dma/ti/k3-udma.c | 117 ++-
drivers/dma/ti/k3-udma.h | 6 ++
2 files changed, 85 insertions(+), 38 deletions(-)
diff --git a/drivers/dma/ti/k3-udma.c b/drivers/dma/ti/k3-udma.c
index f327d436f8ad..0dc3430fea40 100644
--- a/drivers/dma/ti/k3-udma.c
+++ b/drivers/dma/ti/k3-udma.c
@@ -146,6 +146,11 @@ struct udma_rx_flush {
dma_addr_t buffer_paddr;
};
+struct udma_tpl {
+ u8 levels;
+ u32 start_idx[3];
+};
+
struct udma_dev {
struct dma_device ddev;
struct device *dev;
@@ -153,8 +158,9 @@ struct udma_dev {
const struct udma_match_data *match_data;
const struct udma_soc_data *soc_data;
- u8 tpl_levels;
- u32 tpl_start_idx[3];
+ struct udma_tpl bchan_tpl;
+ struct udma_tpl tchan_tpl;
+ struct udma_tpl rchan_tpl;
size_t desc_align; /* alignment to use for descriptors */
@@ -1276,10 +1282,10 @@ static struct udma_##res *__udma_reserve_##res(struct
udma_dev *ud, \
} else {\
int start; \
\
- if (tpl >= ud->tpl_levels) \
- tpl = ud->tpl_levels - 1; \
+ if (tpl >= ud->res##_tpl.levels)\
+ tpl = ud->res##_tpl.levels - 1; \
\
- start = ud->tpl_start_idx[tpl]; \
+ start = ud->res##_tpl.start_idx[tpl]; \
\
id = find_next_zero_bit(ud->res##_map, ud->res##_cnt, \
start); \
@@ -1292,29 +1298,14 @@ static struct udma_##res *__udma_reserve_##res(struct
udma_dev *ud, \
return >res##s[id]; \
}
+UDMA_RESERVE_RESOURCE(bchan);
UDMA_RESERVE_RESOURCE(tchan);
UDMA_RESERVE_RESOURCE(rchan);
-static struct udma_bchan *__bcdma_reserve_bchan(struct udma_dev *ud, int id)
-{
- if (id >= 0) {
- if (test_bit(id, ud->bchan_map)) {
- dev_err(ud->dev, "bchan%d is in use\n", id);
- return ERR_PTR(-ENOENT);
- }
- } else {
- id = find_next_zero_bit(ud->bchan_map, ud->bchan_cnt, 0);
- if (id == ud->bchan_cnt)
- return ERR_PTR(-ENOENT);
- }
-
- set_bit(id, ud->bchan_map);
- return >bchans[id];
-}
-
static int bcdma_get_bchan(struct udma_chan *uc)
{
struct udma_dev *ud = uc->ud;
+ enum udma_tp_level tpl;
if (uc->bchan) {
dev_dbg(ud->dev, "chan%d: already have bchan%d allocated\n",
@@ -1322,7 +1313,16 @@ static int bcdma_get_bchan(struct udma_chan *uc)
return 0;
}
- uc->bchan = __bcdma_reserve_bchan(ud, -1);
+ /*
+* Use normal channels for peripherals, and highest TPL channel for
+* mem2mem
+*/
+ if (uc->config.tr_trigger_type)
+ tpl = 0;
+ else
+ tpl = ud->bchan_tpl.levels - 1;
+
+ uc->bchan = __udma_reserve_bchan(ud, tpl, -1);
if (IS_ERR(uc->bchan))
return PTR_ERR(uc->bchan);
@@ -1384,8 +1384,11 @@ static int udma_get_chan_pair(struct udma_chan *uc)
/* Can be optimized, but let's have it like this for now */
end = min(ud->tchan_cnt, ud->rchan_cnt);
- /* Try to use the highest TPL channel pair for MEM_TO_MEM channels */
- chan_id = ud->tpl_start_idx[ud->tpl_levels - 1];
+ /*
+* Try to use the highest TPL channel pair for MEM_TO_MEM channels
+* Note: in UDMAP the channel TPL is symmetric between tchan and rchan
+*/
+ chan_id = ud->tchan_tpl.start_idx[ud->tchan_tpl.levels - 1];
for (; chan_id < end; chan_id++) {
if (!test_bit(chan_id, ud->tchan_map) &&
!test_bit(chan_id, ud->rchan_map))
@@ -4036,23 +4039,27 @@ static int udma_setup_resources(struct udma_dev *ud)
cap3 = udma_read(
[PATCH v3 20/20] dmaengine: ti: k3-udma-glue: Add support for K3 PKTDMA
From: Vignesh Raghavendra
This commit adds support for PKTDMA in k3-udma glue driver. Use new
psil_endpoint_config struct to get static data for a given channel or a
flow during setup. Make sure that the RX flows being mapped to a RX
channel is within the range of flows that is been allocated to that RX
channel.
Signed-off-by: Vignesh Raghavendra
Signed-off-by: Peter Ujfalusi
---
drivers/dma/ti/k3-udma-glue.c| 291 +++
drivers/dma/ti/k3-udma-private.c | 24 +++
drivers/dma/ti/k3-udma.h | 4 +
include/linux/dma/k3-udma-glue.h | 8 +
4 files changed, 289 insertions(+), 38 deletions(-)
diff --git a/drivers/dma/ti/k3-udma-glue.c b/drivers/dma/ti/k3-udma-glue.c
index e6ebcd98c02a..4fdd9f06b723 100644
--- a/drivers/dma/ti/k3-udma-glue.c
+++ b/drivers/dma/ti/k3-udma-glue.c
@@ -22,6 +22,7 @@
struct k3_udma_glue_common {
struct device *dev;
+ struct device chan_dev;
struct udma_dev *udmax;
const struct udma_tisci_rm *tisci_rm;
struct k3_ringacc *ringacc;
@@ -32,7 +33,8 @@ struct k3_udma_glue_common {
bool epib;
u32 psdata_size;
u32 swdata_size;
- u32 atype;
+ u32 atype_asel;
+ struct psil_endpoint_config *ep_config;
};
struct k3_udma_glue_tx_channel {
@@ -53,6 +55,8 @@ struct k3_udma_glue_tx_channel {
bool tx_filt_einfo;
bool tx_filt_pswords;
bool tx_supr_tdpkt;
+
+ int udma_tflow_id;
};
struct k3_udma_glue_rx_flow {
@@ -81,6 +85,16 @@ struct k3_udma_glue_rx_channel {
u32 flows_ready;
};
+static void k3_udma_chan_dev_release(struct device *dev)
+{
+ /* The struct containing the device is devm managed */
+}
+
+static struct class k3_udma_glue_devclass = {
+ .name = "k3_udma_glue_chan",
+ .dev_release= k3_udma_chan_dev_release,
+};
+
#define K3_UDMAX_TDOWN_TIMEOUT_US 1000
static int of_k3_udma_glue_parse(struct device_node *udmax_np,
@@ -100,7 +114,6 @@ static int of_k3_udma_glue_parse_chn(struct device_node
*chn_np,
const char *name, struct k3_udma_glue_common *common,
bool tx_chn)
{
- struct psil_endpoint_config *ep_config;
struct of_phandle_args dma_spec;
u32 thread_id;
int ret = 0;
@@ -117,15 +130,26 @@ static int of_k3_udma_glue_parse_chn(struct device_node
*chn_np,
_spec))
return -ENOENT;
+ ret = of_k3_udma_glue_parse(dma_spec.np, common);
+ if (ret)
+ goto out_put_spec;
+
thread_id = dma_spec.args[0];
if (dma_spec.args_count == 2) {
- if (dma_spec.args[1] > 2) {
+ if (dma_spec.args[1] > 2 && !xudma_is_pktdma(common->udmax)) {
dev_err(common->dev, "Invalid channel atype: %u\n",
dma_spec.args[1]);
ret = -EINVAL;
goto out_put_spec;
}
- common->atype = dma_spec.args[1];
+ if (dma_spec.args[1] > 15 && xudma_is_pktdma(common->udmax)) {
+ dev_err(common->dev, "Invalid channel asel: %u\n",
+ dma_spec.args[1]);
+ ret = -EINVAL;
+ goto out_put_spec;
+ }
+
+ common->atype_asel = dma_spec.args[1];
}
if (tx_chn && !(thread_id & K3_PSIL_DST_THREAD_ID_OFFSET)) {
@@ -139,25 +163,23 @@ static int of_k3_udma_glue_parse_chn(struct device_node
*chn_np,
}
/* get psil endpoint config */
- ep_config = psil_get_ep_config(thread_id);
- if (IS_ERR(ep_config)) {
+ common->ep_config = psil_get_ep_config(thread_id);
+ if (IS_ERR(common->ep_config)) {
dev_err(common->dev,
"No configuration for psi-l thread 0x%04x\n",
thread_id);
- ret = PTR_ERR(ep_config);
+ ret = PTR_ERR(common->ep_config);
goto out_put_spec;
}
- common->epib = ep_config->needs_epib;
- common->psdata_size = ep_config->psd_size;
+ common->epib = common->ep_config->needs_epib;
+ common->psdata_size = common->ep_config->psd_size;
if (tx_chn)
common->dst_thread = thread_id;
else
common->src_thread = thread_id;
- ret = of_k3_udma_glue_parse(dma_spec.np, common);
-
out_put_spec:
of_node_put(dma_spec.np);
return ret;
@@ -223,7 +245,7 @@ static int k3_udma_glue_cfg_tx_chn(struct
k3_udma_glue_tx_channel *tx_chn)
req.tx_supr_tdpkt = 1;
req.tx_fetch_size = tx_chn->common.hdesc_size >> 2;
req.txcq_qnum = k3_ringacc_get_ring_id(tx_chn->ringtxcq);
-
[PATCH v3 08/20] dmaengine: Add support for per channel coherency handling
If the DMA device supports per channel coherency configuration (a channel
can be configured to have coherent or not coherent view) then a single
device (the DMA controller's device) can not be used for dma_api for all
channels as channels can have different coherency.
Introduce custom_dma_mapping flag for the dma_chan and a new helper to get
the device pointer to be used for dma_api for the given channel.
Client drivers should be updated to be able to support per channel
coherency by:
- dma_map_single(chan->device->dev, ptr, size, DMA_TO_DEVICE);
+ struct device *dma_dev = dmaengine_get_dma_device(chan);
+
+ dma_map_single(dma_dev, ptr, size, DMA_TO_DEVICE);
Signed-off-by: Peter Ujfalusi
---
include/linux/dmaengine.h | 12
1 file changed, 12 insertions(+)
diff --git a/include/linux/dmaengine.h b/include/linux/dmaengine.h
index aed44888cad3..68130f5f599e 100644
--- a/include/linux/dmaengine.h
+++ b/include/linux/dmaengine.h
@@ -357,11 +357,14 @@ struct dma_chan {
* @chan: driver channel device
* @device: sysfs device
* @dev_id: parent dma_device dev_id
+ * @chan_dma_dev: The channel is using custom/different dma-mapping
+ * compared to the parent dma_device
*/
struct dma_chan_dev {
struct dma_chan *chan;
struct device device;
int dev_id;
+ bool chan_dma_dev;
};
/**
@@ -1618,4 +1621,13 @@ dmaengine_get_direction_text(enum dma_transfer_direction
dir)
return "invalid";
}
}
+
+static inline struct device *dmaengine_get_dma_device(struct dma_chan *chan)
+{
+ if (chan->dev->chan_dma_dev)
+ return >dev->device;
+
+ return chan->device->dev;
+}
+
#endif /* DMAENGINE_H */
--
Peter
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
[PATCH v3 10/20] dmaengine: dmatest: Use dmaengine_get_dma_device
By using the dmaengine_get_dma_device() to get the device for
dma_api use, the dmatest can support per channel coherency if it is
supported by the DMA controller.
Signed-off-by: Peter Ujfalusi
---
drivers/dma/dmatest.c | 13 -
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/drivers/dma/dmatest.c b/drivers/dma/dmatest.c
index a3a172173e34..f696246f57fd 100644
--- a/drivers/dma/dmatest.c
+++ b/drivers/dma/dmatest.c
@@ -573,6 +573,7 @@ static int dmatest_func(void *data)
struct dmatest_params *params;
struct dma_chan *chan;
struct dma_device *dev;
+ struct device *dma_dev;
unsigned interror_count;
unsigned intfailed_tests = 0;
unsigned inttotal_tests = 0;
@@ -606,6 +607,8 @@ static int dmatest_func(void *data)
params = >params;
chan = thread->chan;
dev = chan->device;
+ dma_dev = dmaengine_get_dma_device(chan);
+
src = >src;
dst = >dst;
if (thread->type == DMA_MEMCPY) {
@@ -730,7 +733,7 @@ static int dmatest_func(void *data)
filltime = ktime_add(filltime, diff);
}
- um = dmaengine_get_unmap_data(dev->dev, src->cnt + dst->cnt,
+ um = dmaengine_get_unmap_data(dma_dev, src->cnt + dst->cnt,
GFP_KERNEL);
if (!um) {
failed_tests++;
@@ -745,10 +748,10 @@ static int dmatest_func(void *data)
struct page *pg = virt_to_page(buf);
unsigned long pg_off = offset_in_page(buf);
- um->addr[i] = dma_map_page(dev->dev, pg, pg_off,
+ um->addr[i] = dma_map_page(dma_dev, pg, pg_off,
um->len, DMA_TO_DEVICE);
srcs[i] = um->addr[i] + src->off;
- ret = dma_mapping_error(dev->dev, um->addr[i]);
+ ret = dma_mapping_error(dma_dev, um->addr[i]);
if (ret) {
result("src mapping error", total_tests,
src->off, dst->off, len, ret);
@@ -763,9 +766,9 @@ static int dmatest_func(void *data)
struct page *pg = virt_to_page(buf);
unsigned long pg_off = offset_in_page(buf);
- dsts[i] = dma_map_page(dev->dev, pg, pg_off, um->len,
+ dsts[i] = dma_map_page(dma_dev, pg, pg_off, um->len,
DMA_BIDIRECTIONAL);
- ret = dma_mapping_error(dev->dev, dsts[i]);
+ ret = dma_mapping_error(dma_dev, dsts[i]);
if (ret) {
result("dst mapping error", total_tests,
src->off, dst->off, len, ret);
--
Peter
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
[PATCH v3 17/20] dmaengine: ti: k3-udma: Initial support for K3 BCDMA
One of the DMAs introduced with AM64 is the Block Copy DMA (BCDMA).
It serves similar purpose as K3 UDMAP channels in TR mode.
The rings for the BCDMA is integrated within the DMA itself instead of
using rings from the general purpose ringacc.
A BCDMA have two different type of channels:
- Block Copy Channels (bchan)
- Split Channels (tchan and rchan)
tchan and rchan can be used to service PSI-L peripherals, similarly to
K3 UDMA channels.
bchan can be only used for block copy operation (TR type15) like the
paired K3 UDMA tchan/rchan configured in block copy mode.
bchans can be also used to service peripherals directly if an external
trigger is selected for the channel.
Most of the driver code can be reused for BCDMA bchan/tchan/rchan support
but new setup and allocation functions are needed to handle the
differences between the DMAs.
Signed-off-by: Peter Ujfalusi
---
drivers/dma/ti/k3-udma.c | 1384 ++
drivers/dma/ti/k3-udma.h | 12 +-
2 files changed, 1245 insertions(+), 151 deletions(-)
diff --git a/drivers/dma/ti/k3-udma.c b/drivers/dma/ti/k3-udma.c
index b89afa602532..f327d436f8ad 100644
--- a/drivers/dma/ti/k3-udma.c
+++ b/drivers/dma/ti/k3-udma.c
@@ -26,6 +26,7 @@
#include
#include
#include
+#include
#include
#include "../virt-dma.h"
@@ -55,14 +56,25 @@ struct udma_static_tr {
struct udma_chan;
+enum k3_dma_type {
+ DMA_TYPE_UDMA = 0,
+ DMA_TYPE_BCDMA,
+};
+
enum udma_mmr {
MMR_GCFG = 0,
+ MMR_BCHANRT,
MMR_RCHANRT,
MMR_TCHANRT,
MMR_LAST,
};
-static const char * const mmr_names[] = { "gcfg", "rchanrt", "tchanrt" };
+static const char * const mmr_names[] = {
+ [MMR_GCFG] = "gcfg",
+ [MMR_BCHANRT] = "bchanrt",
+ [MMR_RCHANRT] = "rchanrt",
+ [MMR_TCHANRT] = "tchanrt",
+};
struct udma_tchan {
void __iomem *reg_rt;
@@ -72,6 +84,8 @@ struct udma_tchan {
struct k3_ring *tc_ring; /* Transmit Completion ring */
};
+#define udma_bchan udma_tchan
+
struct udma_rflow {
int id;
struct k3_ring *fd_ring; /* Free Descriptor ring */
@@ -84,11 +98,25 @@ struct udma_rchan {
int id;
};
+struct udma_oes_offsets {
+ /* K3 UDMA Output Event Offset */
+ u32 udma_rchan;
+
+ /* BCDMA Output Event Offsets */
+ u32 bcdma_bchan_data;
+ u32 bcdma_bchan_ring;
+ u32 bcdma_tchan_data;
+ u32 bcdma_tchan_ring;
+ u32 bcdma_rchan_data;
+ u32 bcdma_rchan_ring;
+};
+
#define UDMA_FLAG_PDMA_ACC32 BIT(0)
#define UDMA_FLAG_PDMA_BURST BIT(1)
#define UDMA_FLAG_TDTYPE BIT(2)
struct udma_match_data {
+ enum k3_dma_type type;
u32 psil_base;
bool enable_memcpy_support;
u32 flags;
@@ -96,7 +124,8 @@ struct udma_match_data {
};
struct udma_soc_data {
- u32 rchan_oes_offset;
+ struct udma_oes_offsets oes;
+ u32 bcdma_trigger_event_offset;
};
struct udma_hwdesc {
@@ -139,16 +168,19 @@ struct udma_dev {
struct udma_rx_flush rx_flush;
+ int bchan_cnt;
int tchan_cnt;
int echan_cnt;
int rchan_cnt;
int rflow_cnt;
+ unsigned long *bchan_map;
unsigned long *tchan_map;
unsigned long *rchan_map;
unsigned long *rflow_gp_map;
unsigned long *rflow_gp_map_allocated;
unsigned long *rflow_in_use;
+ struct udma_bchan *bchans;
struct udma_tchan *tchans;
struct udma_rchan *rchans;
struct udma_rflow *rflows;
@@ -156,6 +188,7 @@ struct udma_dev {
struct udma_chan *channels;
u32 psil_base;
u32 atype;
+ u32 asel;
};
struct udma_desc {
@@ -200,6 +233,7 @@ struct udma_chan_config {
bool notdpkt; /* Suppress sending TDC packet */
int remote_thread_id;
u32 atype;
+ u32 asel;
u32 src_thread;
u32 dst_thread;
enum psil_endpoint_type ep_type;
@@ -207,6 +241,8 @@ struct udma_chan_config {
bool enable_burst;
enum udma_tp_level channel_tpl; /* Channel Throughput Level */
+ u32 tr_trigger_type;
+
enum dma_transfer_direction dir;
};
@@ -214,11 +250,13 @@ struct udma_chan {
struct virt_dma_chan vc;
struct dma_slave_config cfg;
struct udma_dev *ud;
+ struct device *dma_dev;
struct udma_desc *desc;
struct udma_desc *terminated_desc;
struct udma_static_tr static_tr;
char *name;
+ struct udma_bchan *bchan;
struct udma_tchan *tchan;
struct udma_rchan *rchan;
struct udma_rflow *rflow;
@@ -354,6 +392,30 @@ static int navss_psil_unpair(struct udma_dev *ud, u32
src_thread,
src_thread, dst_thread);
}
+static void k3_configure_chan_coherency(struct dma_chan *chan, u32
[PATCH v3 16/20] soc: ti: k3-ringacc: add AM64 DMA rings support.
From: Grygorii Strashko
The DMAs in AM64 have built in rings compared to AM654/J721e/J7200 where a
separate and generic ringacc is used.
The ring SW interface is similar to ringacc with some major architectural
differences, like
They are part of the DMA (BCDMA or PKTDMA).
They are dual mode rings are modeled as pair of Rings objects which has
common configuration and memory buffer, but separate real-time control
register sets for each direction mem2dev (forward) and dev2mem (reverse).
The ringacc driver must be initialized for DMA rings use with
k3_ringacc_dmarings_init() as it is not an independent device as ringacc
is.
AM64 rings must be requested only using k3_ringacc_request_rings_pair(),
and forward ring must always be initialized/configured. After this any
other Ringacc APIs can be used without any callers changes.
Signed-off-by: Grygorii Strashko
Signed-off-by: Peter Ujfalusi
---
drivers/soc/ti/k3-ringacc.c | 325 +-
include/linux/soc/ti/k3-ringacc.h | 17 ++
2 files changed, 335 insertions(+), 7 deletions(-)
diff --git a/drivers/soc/ti/k3-ringacc.c b/drivers/soc/ti/k3-ringacc.c
index 119164abcb41..c88c305ba367 100644
--- a/drivers/soc/ti/k3-ringacc.c
+++ b/drivers/soc/ti/k3-ringacc.c
@@ -11,6 +11,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -21,6 +22,7 @@ static LIST_HEAD(k3_ringacc_list);
static DEFINE_MUTEX(k3_ringacc_list_lock);
#define K3_RINGACC_CFG_RING_SIZE_ELCNT_MASKGENMASK(19, 0)
+#define K3_DMARING_CFG_RING_SIZE_ELCNT_MASKGENMASK(15, 0)
/**
* struct k3_ring_rt_regs - The RA realtime Control/Status Registers region
@@ -43,7 +45,13 @@ struct k3_ring_rt_regs {
u32 hwindx;
};
-#define K3_RINGACC_RT_REGS_STEP0x1000
+#define K3_RINGACC_RT_REGS_STEP0x1000
+#define K3_DMARING_RT_REGS_STEP0x2000
+#define K3_DMARING_RT_REGS_REVERSE_OFS 0x1000
+#define K3_RINGACC_RT_OCC_MASK GENMASK(20, 0)
+#define K3_DMARING_RT_OCC_TDOWN_COMPLETE BIT(31)
+#define K3_DMARING_RT_DB_ENTRY_MASKGENMASK(7, 0)
+#define K3_DMARING_RT_DB_TDOWN_ACK BIT(31)
/**
* struct k3_ring_fifo_regs - The Ring Accelerator Queues Registers region
@@ -122,6 +130,7 @@ struct k3_ring_state {
u32 occ;
u32 windex;
u32 rindex;
+ u32 tdown_complete:1;
};
/**
@@ -143,6 +152,7 @@ struct k3_ring_state {
* @use_count: Use count for shared rings
* @proxy_id: RA Ring Proxy Id (only if @K3_RINGACC_RING_USE_PROXY)
* @dma_dev: device to be used for DMA API (allocation, mapping)
+ * @asel: Address Space Select value for physical addresses
*/
struct k3_ring {
struct k3_ring_rt_regs __iomem *rt;
@@ -157,12 +167,15 @@ struct k3_ring {
u32 flags;
#define K3_RING_FLAG_BUSY BIT(1)
#define K3_RING_FLAG_SHAREDBIT(2)
+#define K3_RING_FLAG_REVERSE BIT(3)
struct k3_ring_state state;
u32 ring_id;
struct k3_ringacc *parent;
u32 use_count;
int proxy_id;
struct device *dma_dev;
+ u32 asel;
+#define K3_ADDRESS_ASEL_SHIFT 48
};
struct k3_ringacc_ops {
@@ -188,6 +201,7 @@ struct k3_ringacc_ops {
* @tisci_ring_ops: ti-sci rings ops
* @tisci_dev_id: ti-sci device id
* @ops: SoC specific ringacc operation
+ * @dma_rings: indicate DMA ring (dual ring within BCDMA/PKTDMA)
*/
struct k3_ringacc {
struct device *dev;
@@ -210,6 +224,7 @@ struct k3_ringacc {
u32 tisci_dev_id;
const struct k3_ringacc_ops *ops;
+ bool dma_rings;
};
/**
@@ -221,6 +236,21 @@ struct k3_ringacc_soc_data {
unsigned dma_ring_reset_quirk:1;
};
+static int k3_ringacc_ring_read_occ(struct k3_ring *ring)
+{
+ return readl(>rt->occ) & K3_RINGACC_RT_OCC_MASK;
+}
+
+static void k3_ringacc_ring_update_occ(struct k3_ring *ring)
+{
+ u32 val;
+
+ val = readl(>rt->occ);
+
+ ring->state.occ = val & K3_RINGACC_RT_OCC_MASK;
+ ring->state.tdown_complete = !!(val & K3_DMARING_RT_OCC_TDOWN_COMPLETE);
+}
+
static long k3_ringacc_ring_get_fifo_pos(struct k3_ring *ring)
{
return K3_RINGACC_FIFO_WINDOW_SIZE_BYTES -
@@ -234,12 +264,24 @@ static void *k3_ringacc_get_elm_addr(struct k3_ring
*ring, u32 idx)
static int k3_ringacc_ring_push_mem(struct k3_ring *ring, void *elem);
static int k3_ringacc_ring_pop_mem(struct k3_ring *ring, void *elem);
+static int k3_dmaring_fwd_pop(struct k3_ring *ring, void *elem);
+static int k3_dmaring_reverse_pop(struct k3_ring *ring, void *elem);
static struct k3_ring_ops k3_ring_mode_ring_ops = {
.push_tail = k3_ringacc_ring_push_mem,
.pop_head = k3_ringacc_ring_pop_mem,
};
+static struct k3_ring_ops k3_dmaring_fwd_ops = {
+ .push_tail = k3_ringacc_ring_push_
[PATCH v3 02/20] dmaengine: ti: k3-udma: Wait for peer teardown completion if supported
Set the TDTYPE if it is supported on the platform (j721e) which will cause
UDMAP to wait for the remote peer to finish the teardown before returning
the teardown completed message.
Signed-off-by: Peter Ujfalusi
Tested-by: Keerthy
Reviewed-by: Grygorii Strashko
---
drivers/dma/ti/k3-udma.c | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/dma/ti/k3-udma.c b/drivers/dma/ti/k3-udma.c
index 0e8426dd18a7..eee43757e774 100644
--- a/drivers/dma/ti/k3-udma.c
+++ b/drivers/dma/ti/k3-udma.c
@@ -86,6 +86,7 @@ struct udma_rchan {
#define UDMA_FLAG_PDMA_ACC32 BIT(0)
#define UDMA_FLAG_PDMA_BURST BIT(1)
+#define UDMA_FLAG_TDTYPE BIT(2)
struct udma_match_data {
u32 psil_base;
@@ -1589,6 +1590,13 @@ static int udma_tisci_tx_channel_config(struct udma_chan
*uc)
req_tx.tx_fetch_size = fetch_size >> 2;
req_tx.txcq_qnum = tc_ring;
req_tx.tx_atype = uc->config.atype;
+ if (uc->config.ep_type == PSIL_EP_PDMA_XY &&
+ ud->match_data->flags & UDMA_FLAG_TDTYPE) {
+ /* wait for peer to complete the teardown for PDMAs */
+ req_tx.valid_params |=
+ TI_SCI_MSG_VALUE_RM_UDMAP_CH_TX_TDTYPE_VALID;
+ req_tx.tx_tdtype = 1;
+ }
ret = tisci_ops->tx_ch_cfg(tisci_rm->tisci, _tx);
if (ret)
@@ -3105,14 +3113,14 @@ static struct udma_match_data am654_mcu_data = {
static struct udma_match_data j721e_main_data = {
.psil_base = 0x1000,
.enable_memcpy_support = true,
- .flags = UDMA_FLAG_PDMA_ACC32 | UDMA_FLAG_PDMA_BURST,
+ .flags = UDMA_FLAG_PDMA_ACC32 | UDMA_FLAG_PDMA_BURST | UDMA_FLAG_TDTYPE,
.statictr_z_mask = GENMASK(23, 0),
};
static struct udma_match_data j721e_mcu_data = {
.psil_base = 0x6000,
.enable_memcpy_support = false, /* MEM_TO_MEM is slow via MCU UDMA */
- .flags = UDMA_FLAG_PDMA_ACC32 | UDMA_FLAG_PDMA_BURST,
+ .flags = UDMA_FLAG_PDMA_ACC32 | UDMA_FLAG_PDMA_BURST | UDMA_FLAG_TDTYPE,
.statictr_z_mask = GENMASK(23, 0),
};
--
Peter
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
[PATCH v3 05/20] dmaengine: ti: k3-udma-glue: Get the ringacc from udma_dev
If of_xudma_dev_get() returns with the valid udma_dev then the driver
already got the ringacc, there is no need to execute
of_k3_ringacc_get_by_phandle() for each channel via the glue layer.
Signed-off-by: Peter Ujfalusi
---
drivers/dma/ti/k3-udma-glue.c| 6 +-
drivers/dma/ti/k3-udma-private.c | 6 ++
drivers/dma/ti/k3-udma.h | 1 +
3 files changed, 8 insertions(+), 5 deletions(-)
diff --git a/drivers/dma/ti/k3-udma-glue.c b/drivers/dma/ti/k3-udma-glue.c
index 29d1524d1916..8a8988be4175 100644
--- a/drivers/dma/ti/k3-udma-glue.c
+++ b/drivers/dma/ti/k3-udma-glue.c
@@ -86,15 +86,11 @@ struct k3_udma_glue_rx_channel {
static int of_k3_udma_glue_parse(struct device_node *udmax_np,
struct k3_udma_glue_common *common)
{
- common->ringacc = of_k3_ringacc_get_by_phandle(udmax_np,
- "ti,ringacc");
- if (IS_ERR(common->ringacc))
- return PTR_ERR(common->ringacc);
-
common->udmax = of_xudma_dev_get(udmax_np, NULL);
if (IS_ERR(common->udmax))
return PTR_ERR(common->udmax);
+ common->ringacc = xudma_get_ringacc(common->udmax);
common->tisci_rm = xudma_dev_get_tisci_rm(common->udmax);
return 0;
diff --git a/drivers/dma/ti/k3-udma-private.c b/drivers/dma/ti/k3-udma-private.c
index c9fb1d832581..0856721d0b04 100644
--- a/drivers/dma/ti/k3-udma-private.c
+++ b/drivers/dma/ti/k3-udma-private.c
@@ -56,6 +56,12 @@ struct device *xudma_get_device(struct udma_dev *ud)
}
EXPORT_SYMBOL(xudma_get_device);
+struct k3_ringacc *xudma_get_ringacc(struct udma_dev *ud)
+{
+ return ud->ringacc;
+}
+EXPORT_SYMBOL(xudma_get_ringacc);
+
u32 xudma_dev_get_psil_base(struct udma_dev *ud)
{
return ud->psil_base;
diff --git a/drivers/dma/ti/k3-udma.h b/drivers/dma/ti/k3-udma.h
index d1cace0cb43b..b4334b1b7b14 100644
--- a/drivers/dma/ti/k3-udma.h
+++ b/drivers/dma/ti/k3-udma.h
@@ -113,6 +113,7 @@ int xudma_navss_psil_unpair(struct udma_dev *ud, u32
src_thread,
struct udma_dev *of_xudma_dev_get(struct device_node *np, const char
*property);
struct device *xudma_get_device(struct udma_dev *ud);
+struct k3_ringacc *xudma_get_ringacc(struct udma_dev *ud);
void xudma_dev_put(struct udma_dev *ud);
u32 xudma_dev_get_psil_base(struct udma_dev *ud);
struct udma_tisci_rm *xudma_dev_get_tisci_rm(struct udma_dev *ud);
--
Peter
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
[PATCH v3 03/20] dmaengine: ti: k3-udma: Add support for second resource range from sysfw
Resource allocation via sysfw can use up to two ranges per resource subtype
to support more complex resource assignment, mainly for DMA channels.
Take the second range also into consideration when setting up the maps for
available resources.
Signed-off-by: Peter Ujfalusi
---
drivers/dma/ti/k3-udma.c | 55 ++--
1 file changed, 31 insertions(+), 24 deletions(-)
diff --git a/drivers/dma/ti/k3-udma.c b/drivers/dma/ti/k3-udma.c
index eee43757e774..b89afa602532 100644
--- a/drivers/dma/ti/k3-udma.c
+++ b/drivers/dma/ti/k3-udma.c
@@ -3174,12 +3174,22 @@ static int udma_get_mmrs(struct platform_device *pdev,
struct udma_dev *ud)
return 0;
}
+static void udma_mark_resource_ranges(struct udma_dev *ud, unsigned long *map,
+ struct ti_sci_resource_desc *rm_desc,
+ char *name)
+{
+ bitmap_clear(map, rm_desc->start, rm_desc->num);
+ bitmap_clear(map, rm_desc->start_sec, rm_desc->num_sec);
+ dev_dbg(ud->dev, "ti_sci resource range for %s: %d:%d | %d:%d\n", name,
+ rm_desc->start, rm_desc->num, rm_desc->start_sec,
+ rm_desc->num_sec);
+}
+
static int udma_setup_resources(struct udma_dev *ud)
{
struct device *dev = ud->dev;
int ch_count, ret, i, j;
u32 cap2, cap3;
- struct ti_sci_resource_desc *rm_desc;
struct ti_sci_resource *rm_res, irq_res;
struct udma_tisci_rm *tisci_rm = >tisci_rm;
static const char * const range_names[] = { "ti,sci-rm-range-tchan",
@@ -3264,13 +3274,9 @@ static int udma_setup_resources(struct udma_dev *ud)
bitmap_zero(ud->tchan_map, ud->tchan_cnt);
} else {
bitmap_fill(ud->tchan_map, ud->tchan_cnt);
- for (i = 0; i < rm_res->sets; i++) {
- rm_desc = _res->desc[i];
- bitmap_clear(ud->tchan_map, rm_desc->start,
-rm_desc->num);
- dev_dbg(dev, "ti-sci-res: tchan: %d:%d\n",
- rm_desc->start, rm_desc->num);
- }
+ for (i = 0; i < rm_res->sets; i++)
+ udma_mark_resource_ranges(ud, ud->tchan_map,
+ _res->desc[i], "tchan");
}
irq_res.sets = rm_res->sets;
@@ -3280,13 +3286,9 @@ static int udma_setup_resources(struct udma_dev *ud)
bitmap_zero(ud->rchan_map, ud->rchan_cnt);
} else {
bitmap_fill(ud->rchan_map, ud->rchan_cnt);
- for (i = 0; i < rm_res->sets; i++) {
- rm_desc = _res->desc[i];
- bitmap_clear(ud->rchan_map, rm_desc->start,
-rm_desc->num);
- dev_dbg(dev, "ti-sci-res: rchan: %d:%d\n",
- rm_desc->start, rm_desc->num);
- }
+ for (i = 0; i < rm_res->sets; i++)
+ udma_mark_resource_ranges(ud, ud->rchan_map,
+ _res->desc[i], "rchan");
}
irq_res.sets += rm_res->sets;
@@ -3295,12 +3297,21 @@ static int udma_setup_resources(struct udma_dev *ud)
for (i = 0; i < rm_res->sets; i++) {
irq_res.desc[i].start = rm_res->desc[i].start;
irq_res.desc[i].num = rm_res->desc[i].num;
+ irq_res.desc[i].start_sec = rm_res->desc[i].start_sec;
+ irq_res.desc[i].num_sec = rm_res->desc[i].num_sec;
}
rm_res = tisci_rm->rm_ranges[RM_RANGE_RCHAN];
for (j = 0; j < rm_res->sets; j++, i++) {
- irq_res.desc[i].start = rm_res->desc[j].start +
+ if (rm_res->desc[j].num) {
+ irq_res.desc[i].start = rm_res->desc[j].start +
ud->soc_data->rchan_oes_offset;
- irq_res.desc[i].num = rm_res->desc[j].num;
+ irq_res.desc[i].num = rm_res->desc[j].num;
+ }
+ if (rm_res->desc[j].num_sec) {
+ irq_res.desc[i].start_sec = rm_res->desc[j].start_sec +
+ ud->soc_data->rchan_oes_offset;
+ irq_res.desc[i].num_sec = rm_res->desc[j].num_sec;
+ }
}
ret = ti_sci_inta_msi_domain_alloc_irqs(ud->dev, _res);
kfree(irq_res.desc);
@@ -3316,13 +3327,9 @@ static int udma_setup_resources(struct udma_dev *ud)
bitmap_clear(ud->rflow_gp_map, ud->rchan_cnt,
ud->rflow_cnt - ud->rchan_cnt);
[PATCH v3 04/20] dmaengine: ti: k3-udma-glue: Add function to get device pointer for DMA API
Glue layer users should use the device of the DMA for DMA mapping and
allocations as it is the DMA which accesses to descriptors and buffers,
not the clients
Signed-off-by: Peter Ujfalusi
---
drivers/dma/ti/k3-udma-glue.c| 14 ++
drivers/dma/ti/k3-udma-private.c | 6 ++
drivers/dma/ti/k3-udma.h | 1 +
include/linux/dma/k3-udma-glue.h | 4
4 files changed, 25 insertions(+)
diff --git a/drivers/dma/ti/k3-udma-glue.c b/drivers/dma/ti/k3-udma-glue.c
index dfb65e382ab9..29d1524d1916 100644
--- a/drivers/dma/ti/k3-udma-glue.c
+++ b/drivers/dma/ti/k3-udma-glue.c
@@ -493,6 +493,13 @@ int k3_udma_glue_tx_get_irq(struct k3_udma_glue_tx_channel
*tx_chn)
}
EXPORT_SYMBOL_GPL(k3_udma_glue_tx_get_irq);
+struct device *
+ k3_udma_glue_tx_get_dma_device(struct k3_udma_glue_tx_channel *tx_chn)
+{
+ return xudma_get_device(tx_chn->common.udmax);
+}
+EXPORT_SYMBOL_GPL(k3_udma_glue_tx_get_dma_device);
+
static int k3_udma_glue_cfg_rx_chn(struct k3_udma_glue_rx_channel *rx_chn)
{
const struct udma_tisci_rm *tisci_rm = rx_chn->common.tisci_rm;
@@ -1201,3 +1208,10 @@ int k3_udma_glue_rx_get_irq(struct
k3_udma_glue_rx_channel *rx_chn,
return flow->virq;
}
EXPORT_SYMBOL_GPL(k3_udma_glue_rx_get_irq);
+
+struct device *
+ k3_udma_glue_rx_get_dma_device(struct k3_udma_glue_rx_channel *rx_chn)
+{
+ return xudma_get_device(rx_chn->common.udmax);
+}
+EXPORT_SYMBOL_GPL(k3_udma_glue_rx_get_dma_device);
diff --git a/drivers/dma/ti/k3-udma-private.c b/drivers/dma/ti/k3-udma-private.c
index 8563a392f30b..c9fb1d832581 100644
--- a/drivers/dma/ti/k3-udma-private.c
+++ b/drivers/dma/ti/k3-udma-private.c
@@ -50,6 +50,12 @@ struct udma_dev *of_xudma_dev_get(struct device_node *np,
const char *property)
}
EXPORT_SYMBOL(of_xudma_dev_get);
+struct device *xudma_get_device(struct udma_dev *ud)
+{
+ return ud->dev;
+}
+EXPORT_SYMBOL(xudma_get_device);
+
u32 xudma_dev_get_psil_base(struct udma_dev *ud)
{
return ud->psil_base;
diff --git a/drivers/dma/ti/k3-udma.h b/drivers/dma/ti/k3-udma.h
index 09c4529e013d..d1cace0cb43b 100644
--- a/drivers/dma/ti/k3-udma.h
+++ b/drivers/dma/ti/k3-udma.h
@@ -112,6 +112,7 @@ int xudma_navss_psil_unpair(struct udma_dev *ud, u32
src_thread,
u32 dst_thread);
struct udma_dev *of_xudma_dev_get(struct device_node *np, const char
*property);
+struct device *xudma_get_device(struct udma_dev *ud);
void xudma_dev_put(struct udma_dev *ud);
u32 xudma_dev_get_psil_base(struct udma_dev *ud);
struct udma_tisci_rm *xudma_dev_get_tisci_rm(struct udma_dev *ud);
diff --git a/include/linux/dma/k3-udma-glue.h b/include/linux/dma/k3-udma-glue.h
index 5eb34ad973a7..d7c12f31377c 100644
--- a/include/linux/dma/k3-udma-glue.h
+++ b/include/linux/dma/k3-udma-glue.h
@@ -41,6 +41,8 @@ void k3_udma_glue_reset_tx_chn(struct k3_udma_glue_tx_channel
*tx_chn,
u32 k3_udma_glue_tx_get_hdesc_size(struct k3_udma_glue_tx_channel *tx_chn);
u32 k3_udma_glue_tx_get_txcq_id(struct k3_udma_glue_tx_channel *tx_chn);
int k3_udma_glue_tx_get_irq(struct k3_udma_glue_tx_channel *tx_chn);
+struct device *
+ k3_udma_glue_tx_get_dma_device(struct k3_udma_glue_tx_channel *tx_chn);
enum {
K3_UDMA_GLUE_SRC_TAG_LO_KEEP = 0,
@@ -130,5 +132,7 @@ int k3_udma_glue_rx_flow_enable(struct
k3_udma_glue_rx_channel *rx_chn,
u32 flow_idx);
int k3_udma_glue_rx_flow_disable(struct k3_udma_glue_rx_channel *rx_chn,
u32 flow_idx);
+struct device *
+ k3_udma_glue_rx_get_dma_device(struct k3_udma_glue_rx_channel *rx_chn);
#endif /* K3_UDMA_GLUE_H_ */
--
Peter
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
[PATCH v3 15/20] dmaengine: ti: Add support for k3 event routers
In k3 architecture a DMA channel (in TR momde) can be triggered by global
events, origination from different modules.
The events for triggers can be sent from any module which is connected to
PSI-L fabric, but the event number to be sent is DMA channel specific, it
is only known after the channel itself is requested.
The router operation needs to be split up:
- route_allocate: configure the dma_spec for the DMA and store the
configuration which is needed for the router's input
- set_event: callback used by the DMA driver to set the event number for
the channel and enable the routing
Signed-off-by: Peter Ujfalusi
---
include/linux/dma/k3-event-router.h | 16
1 file changed, 16 insertions(+)
create mode 100644 include/linux/dma/k3-event-router.h
diff --git a/include/linux/dma/k3-event-router.h
b/include/linux/dma/k3-event-router.h
new file mode 100644
index ..e3f88b2f87be
--- /dev/null
+++ b/include/linux/dma/k3-event-router.h
@@ -0,0 +1,16 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Copyright (C) 2020 Texas Instruments Incorporated - https://www.ti.com
+ */
+
+#ifndef K3_EVENT_ROUTER_
+#define K3_EVENT_ROUTER_
+
+#include
+
+struct k3_event_route_data {
+ void *priv;
+ int (*set_event)(void *priv, u32 event);
+};
+
+#endif /* K3_EVENT_ROUTER_ */
--
Peter
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
[PATCH v3 12/20] dt-bindings: dma: ti: Add document for K3 PKTDMA
New binding document for
Texas Instruments K3 Packet DMA (PKTDMA).
PKTDMA is introduced as part of AM64.
Signed-off-by: Peter Ujfalusi
---
.../devicetree/bindings/dma/ti/k3-pktdma.yaml | 172 ++
1 file changed, 172 insertions(+)
create mode 100644 Documentation/devicetree/bindings/dma/ti/k3-pktdma.yaml
diff --git a/Documentation/devicetree/bindings/dma/ti/k3-pktdma.yaml
b/Documentation/devicetree/bindings/dma/ti/k3-pktdma.yaml
new file mode 100644
index ..b13ab60cd740
--- /dev/null
+++ b/Documentation/devicetree/bindings/dma/ti/k3-pktdma.yaml
@@ -0,0 +1,172 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/dma/ti/k3-pktdma.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Texas Instruments K3 DMSS PKTDMA Device Tree Bindings
+
+maintainers:
+ - Peter Ujfalusi
+
+description: |
+ The Packet DMA (PKTDMA) is intended to perform similar functions as the
packet
+ mode channels of K3 UDMA-P.
+ PKTDMA only includes Split channels to service PSI-L based peripherals.
+
+ The peripherals can be PSI-L native or legacy, non PSI-L native peripherals
+ with PDMAs. PDMA is tasked to act as a bridge between the PSI-L fabric and
the
+ legacy peripheral.
+
+ PDMAs can be configured via PKTDMA split channel's peer registers to match
+ with the configuration of the legacy peripheral.
+
+allOf:
+ - $ref: /schemas/dma/dma-controller.yaml#
+
+properties:
+ compatible:
+const: ti,am64-dmss-pktdma
+
+ "#dma-cells":
+const: 2
+description: |
+ The first cell is the PSI-L thread ID of the remote (to PKTDMA) end.
+ Valid ranges for thread ID depends on the data movement direction:
+ for source thread IDs (rx): 0 - 0x7fff
+ for destination thread IDs (tx): 0x8000 - 0x
+
+ Please refer to the device documentation for the PSI-L thread map and
also
+ the PSI-L peripheral chapter for the correct thread ID.
+
+ The second cell is the ASEL value for the channel
+
+ reg:
+maxItems: 4
+
+ reg-names:
+items:
+ - const: gcfg
+ - const: rchanrt
+ - const: tchanrt
+ - const: ringrt
+
+ msi-parent: true
+
+ ti,sci-rm-range-tchan:
+$ref: /schemas/types.yaml#/definitions/uint32-array
+description: |
+ Array of PKTDMA split tx channel resource subtypes for resource
allocation
+ for this host
+minItems: 1
+# Should be enough
+maxItems: 255
+items:
+ maximum: 0x3f
+
+ ti,sci-rm-range-tflow:
+$ref: /schemas/types.yaml#/definitions/uint32-array
+description: |
+ Array of PKTDMA split tx flow resource subtypes for resource allocation
+ for this host
+minItems: 1
+# Should be enough
+maxItems: 255
+items:
+ maximum: 0x3f
+
+ ti,sci-rm-range-rchan:
+$ref: /schemas/types.yaml#/definitions/uint32-array
+description: |
+ Array of PKTDMA split rx channel resource subtypes for resource
allocation
+ for this host
+minItems: 1
+# Should be enough
+maxItems: 255
+items:
+ maximum: 0x3f
+
+ ti,sci-rm-range-rflow:
+$ref: /schemas/types.yaml#/definitions/uint32-array
+description: |
+ Array of PKTDMA split rx flow resource subtypes for resource allocation
+ for this host
+minItems: 1
+# Should be enough
+maxItems: 255
+items:
+ maximum: 0x3f
+
+required:
+ - compatible
+ - "#dma-cells"
+ - reg
+ - reg-names
+ - msi-parent
+ - ti,sci
+ - ti,sci-dev-id
+ - ti,sci-rm-range-tchan
+ - ti,sci-rm-range-tflow
+ - ti,sci-rm-range-rchan
+ - ti,sci-rm-range-rflow
+
+unevaluatedProperties: false
+
+examples:
+ - |+
+cbass_main {
+#address-cells = <2>;
+#size-cells = <2>;
+
+main_dmss {
+compatible = "simple-mfd";
+#address-cells = <2>;
+#size-cells = <2>;
+dma-ranges;
+ranges;
+
+ti,sci-dev-id = <25>;
+
+main_pktdma: dma-controller@485c {
+compatible = "ti,am64-dmss-pktdma";
+
+reg = <0x0 0x485c 0x0 0x100>,
+ <0x0 0x4a80 0x0 0x2>,
+ <0x0 0x4aa0 0x0 0x4>,
+ <0x0 0x4b80 0x0 0x40>;
+reg-names = "gcfg", "rchanrt", "tchanrt", "ringrt";
+msi-parent = <_main_dmss>;
+#dma-cells = <2>;
+
+ti,sci = <>;
+ti,sci-dev-id = <30>;
+
+ti,sci-rm-range-tchan = <0x23>, /* UNMAPPED_TX_CHAN */
+<0x24>, /* CPSW_TX_CHAN */
+<0x25>, /* SAUL_TX_0_CHAN */
+<0x26>, /* SAUL_TX_1_CHAN */
+
[PATCH v3 06/20] dmaengine: ti: k3-udma-glue: Configure the dma_dev for rings
Rings in RING mode should be using the DMA device for DMA API as in this
mode the ringacc will not access the ring memory in any ways, but the DMA
is.
Fix up the ring configuration and set the dma_dev unconditionally and let
the ringacc driver to select the correct device to use for DMA API.
Signed-off-by: Peter Ujfalusi
---
drivers/dma/ti/k3-udma-glue.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/dma/ti/k3-udma-glue.c b/drivers/dma/ti/k3-udma-glue.c
index 8a8988be4175..e6ebcd98c02a 100644
--- a/drivers/dma/ti/k3-udma-glue.c
+++ b/drivers/dma/ti/k3-udma-glue.c
@@ -276,6 +276,10 @@ struct k3_udma_glue_tx_channel
*k3_udma_glue_request_tx_chn(struct device *dev,
goto err;
}
+ /* Set the dma_dev for the rings to be configured */
+ cfg->tx_cfg.dma_dev = k3_udma_glue_tx_get_dma_device(tx_chn);
+ cfg->txcq_cfg.dma_dev = cfg->tx_cfg.dma_dev;
+
ret = k3_ringacc_ring_cfg(tx_chn->ringtx, >tx_cfg);
if (ret) {
dev_err(dev, "Failed to cfg ringtx %d\n", ret);
@@ -591,6 +595,10 @@ static int k3_udma_glue_cfg_rx_flow(struct
k3_udma_glue_rx_channel *rx_chn,
goto err_rflow_put;
}
+ /* Set the dma_dev for the rings to be configured */
+ flow_cfg->rx_cfg.dma_dev = k3_udma_glue_rx_get_dma_device(rx_chn);
+ flow_cfg->rxfdq_cfg.dma_dev = flow_cfg->rx_cfg.dma_dev;
+
ret = k3_ringacc_ring_cfg(flow->ringrx, _cfg->rx_cfg);
if (ret) {
dev_err(dev, "Failed to cfg ringrx %d\n", ret);
--
Peter
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
[PATCH v3 07/20] dmaengine: of-dma: Add support for optional router configuration callback
Additional configuration for the DMA event router might be needed for a
channel which can not be done during device_alloc_chan_resources callback
since the router information is not yet present for the drivers.
If there is a need for additional configuration for the channel if DMA
router is in use, then the driver can implement the device_router_config
callback.
Signed-off-by: Peter Ujfalusi
---
drivers/dma/of-dma.c | 10 ++
include/linux/dmaengine.h | 2 ++
2 files changed, 12 insertions(+)
diff --git a/drivers/dma/of-dma.c b/drivers/dma/of-dma.c
index 8a4f608904b9..ec00b20ae8e4 100644
--- a/drivers/dma/of-dma.c
+++ b/drivers/dma/of-dma.c
@@ -75,8 +75,18 @@ static struct dma_chan *of_dma_router_xlate(struct
of_phandle_args *dma_spec,
ofdma->dma_router->route_free(ofdma->dma_router->dev,
route_data);
} else {
+ int ret = 0;
+
chan->router = ofdma->dma_router;
chan->route_data = route_data;
+
+ if (chan->device->device_router_config)
+ ret = chan->device->device_router_config(chan);
+
+ if (ret) {
+ dma_release_channel(chan);
+ chan = ERR_PTR(ret);
+ }
}
/*
diff --git a/include/linux/dmaengine.h b/include/linux/dmaengine.h
index 493a047ed0a2..aed44888cad3 100644
--- a/include/linux/dmaengine.h
+++ b/include/linux/dmaengine.h
@@ -805,6 +805,7 @@ struct dma_filter {
* by tx_status
* @device_alloc_chan_resources: allocate resources and return the
* number of allocated descriptors
+ * @device_router_config: optional callback for DMA router configuration
* @device_free_chan_resources: release DMA channel's resources
* @device_prep_dma_memcpy: prepares a memcpy operation
* @device_prep_dma_xor: prepares a xor operation
@@ -879,6 +880,7 @@ struct dma_device {
enum dma_residue_granularity residue_granularity;
int (*device_alloc_chan_resources)(struct dma_chan *chan);
+ int (*device_router_config)(struct dma_chan *chan);
void (*device_free_chan_resources)(struct dma_chan *chan);
struct dma_async_tx_descriptor *(*device_prep_dma_memcpy)(
--
Peter
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
[PATCH v3 01/20] dmaengine: ti: k3-udma: Correct normal channel offset when uchan_cnt is not 0
According to different sections of the TRM, the hchan_cnt of CAP3 includes
the number of uchan in UDMA, thus the start offset of the normal channels
are hchan_cnt.
Fixes: daf4ad0499aa4 ("dmaengine: ti: k3-udma: Query throughput level
information from hardware")
Signed-off-by: Peter Ujfalusi
---
drivers/dma/ti/k3-udma.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/dma/ti/k3-udma.c b/drivers/dma/ti/k3-udma.c
index e508280b3d70..0e8426dd18a7 100644
--- a/drivers/dma/ti/k3-udma.c
+++ b/drivers/dma/ti/k3-udma.c
@@ -3199,8 +3199,7 @@ static int udma_setup_resources(struct udma_dev *ud)
} else if (UDMA_CAP3_UCHAN_CNT(cap3)) {
ud->tpl_levels = 3;
ud->tpl_start_idx[1] = UDMA_CAP3_UCHAN_CNT(cap3);
- ud->tpl_start_idx[0] = ud->tpl_start_idx[1] +
- UDMA_CAP3_HCHAN_CNT(cap3);
+ ud->tpl_start_idx[0] = UDMA_CAP3_HCHAN_CNT(cap3);
} else if (UDMA_CAP3_HCHAN_CNT(cap3)) {
ud->tpl_levels = 2;
ud->tpl_start_idx[0] = UDMA_CAP3_HCHAN_CNT(cap3);
--
Peter
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
Re: [PATCH v2 10/19] dt-bindings: dma: ti: Add document for K3 BCDMA
Hi Rob, On 07/12/2020 21.42, Rob Herring wrote: > On Tue, Nov 17, 2020 at 12:56:47PM +0200, Peter Ujfalusi wrote: >> New binding document for >> Texas Instruments K3 Block Copy DMA (BCDMA). >> >> BCDMA is introduced as part of AM64. >> >> Signed-off-by: Peter Ujfalusi >> --- >> .../devicetree/bindings/dma/ti/k3-bcdma.yaml | 175 ++ >> 1 file changed, 175 insertions(+) >> create mode 100644 Documentation/devicetree/bindings/dma/ti/k3-bcdma.yaml >> >> diff --git a/Documentation/devicetree/bindings/dma/ti/k3-bcdma.yaml >> b/Documentation/devicetree/bindings/dma/ti/k3-bcdma.yaml >> new file mode 100644 >> index ..c6d76641ebec >> --- /dev/null >> +++ b/Documentation/devicetree/bindings/dma/ti/k3-bcdma.yaml >> @@ -0,0 +1,175 @@ >> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) >> +%YAML 1.2 >> +--- >> +$id: http://devicetree.org/schemas/dma/ti/k3-bcdma.yaml# >> +$schema: http://devicetree.org/meta-schemas/core.yaml# >> + >> +title: Texas Instruments K3 DMSS BCDMA Device Tree Bindings >> + >> +maintainers: >> + - Peter Ujfalusi >> + >> +description: | >> + The Block Copy DMA (BCDMA) is intended to perform similar functions as >> the TR >> + mode channels of K3 UDMA-P. >> + BCDMA includes block copy channels and Split channels. >> + >> + Block copy channels mainly used for memory to memory transfers, but with >> + optional triggers a block copy channel can service peripherals by >> accessing >> + directly to memory mapped registers or area. >> + >> + Split channels can be used to service PSI-L based peripherals. >> + The peripherals can be PSI-L native or legacy, non PSI-L native >> peripherals >> + with PDMAs. PDMA is tasked to act as a bridge between the PSI-L fabric >> and the >> + legacy peripheral. >> + >> + PDMAs can be configured via BCDMA split channel's peer registers to match >> with >> + the configuration of the legacy peripheral. >> + >> +allOf: >> + - $ref: /schemas/dma/dma-controller.yaml# >> + >> +properties: >> + "#dma-cells": >> +const: 3 >> +description: | >> + cell 1: type of the BCDMA channel to be used to service the >> peripheral: >> +0 - split channel >> +1 - block copy channel using global trigger 1 >> +2 - block copy channel using global trigger 2 >> +3 - block copy channel using local trigger >> + >> + cell 2: parameter for the channel: >> +if cell 1 is 0 (split channel): >> + PSI-L thread ID of the remote (to BCDMA) end. >> + Valid ranges for thread ID depends on the data movement direction: >> + for source thread IDs (rx): 0 - 0x7fff >> + for destination thread IDs (tx): 0x8000 - 0x >> + >> + Please refer to the device documentation for the PSI-L thread map >> and >> + also the PSI-L peripheral chapter for the correct thread ID. >> +if cell 1 is 1 or 2 (block copy channel using global trigger): >> + Unused, ignored >> + >> + The trigger must be configured for the channel externally to >> BCDMA, >> + channels using global triggers should not be requested directly, >> but >> + via DMA event router. >> +if cell 1 is 3 (block copy channel using local trigger): >> + bchan number of the locally triggered channel >> + >> + cell 3: ASEL value for the channel >> + >> + compatible: >> +enum: >> + - ti,am64-dmss-bcdma > > Typically, we put 'compatible' first. OK. >> + "#address-cells": >> +const: 2 >> + >> + "#size-cells": >> +const: 2 > > These apply to child nodes, but you don't have any. True, I forgot to remove these. >> + >> + reg: >> +maxItems: 5 >> + >> + reg-names: >> +items: >> + - const: gcfg >> + - const: bchanrt >> + - const: rchanrt >> + - const: tchanrt >> + - const: ringrt >> + >> + msi-parent: true >> + >> + ti,asel: >> +$ref: /schemas/types.yaml#/definitions/uint32 >> +description: ASEL value for non slave channels >> + >> + ti,sci-rm-range-bchan: >> +$ref: /schemas/types.yaml#/definitions/uint32-array >> +description: | >> + Array of BCDMA block-copy channel resource subtypes for resource >> + all
Re: [PATCH v2 00/19] dmaengine/soc: k3-udma: Add support for BCDMA and PKTDMA
Hi Santosh, On 24/11/2020 19.08, Vinod Koul wrote: > On 17-11-20, 12:56, Peter Ujfalusi wrote: >> Hi, >> >> The series have build dependency on ti_sci/soc series (v2): >> https://lore.kernel.org/lkml/20201008115224.1591-1-peter.ujfal...@ti.com/ >> >> Santosh kindly created immutable branch holdinf the series: >> git://git.kernel.org/pub/scm/linux/kernel/git/ssantosh/linux-keystone.git >> for_5.11/drivers-soc > > Santosh, Can I have a signed tag for this please? Can you please provide a tag for Vinod? I'm ready to send v3 with few small fixes and waiting for Rob to get to the binding documents before I do. Thanks, - Péter >> >> The unmapped event handling in INTA is already mainline. >> >> Changes since v1: >> - Both DT binding document has been updated to address all comments and >> suggestions from Rob, all checks are passing on them >> - included new patch to fix the normal channel start offset when ultra-high >> capacity channels are available for the UDMA and updated the BCDMA/PKTDMA >> patches along the same line >> - Re-arranged the patches for Vinod so that the preparational patches and >> fixes >> can be picked up separately (they still have dependency on Santosh's >> branch): >> >> patch 1-5: Fixes and new features for existing devices using UDMA, but the >> the BCDMA/PKTDMA support is building on top of these. >> Build dependency on Santosh's branch >> patch 6: Optional second stage router configuration callback support in >> core >> patch 7-9: Per channel coherency support in core and use it in dmatest. >> patch 10-: Initial AM64 BCDMA and PKTDMA support >> >> The DMSS introduced within AM64 as a simplified Data movement engine is built >> on similar grounds as the K3 NAVSS and UDMAP, but with significant >> architectural >> changes. >> >> - Rings are built into the DMAs >> The DMAs no longer use the general purpose ringacc, all rings has been moved >> inside of the DMAs. The new rings within the DMAs are simplified to be dual >> directional compared to the uni-directional rings in ringacc. >> There is no more of a concept of generic purpose rings, all rings are >> assigned >> to specific channels or flows. >> >> - Per channel coherency support >> The DMAs use the 'ASEL' bits to select data and configuration fetch path. The >> ASEL bits are placed at the unused parts of any address field used by the >> DMAs (pointers to descriptors, addresses in descriptors, ring base >> addresses). >> The ASEL is not part of the address (the DMAs can address 48bits). >> Individual channels can be configured to be coherent (via ACP port) or non >> coherent individually by configuring the ASEL to appropriate value. >> >> - Two different DMAs (well, three actually) >> PKTDMA >> Similar to UDMAP channels configured in packet mode. >> The flow configuration of the channels has changed significantly in a way >> that >> each channel have at least one flow assigned at design time and each flow is >> directly mapped to corresponding ring. >> When multiple flows are set, the channel can only use the flows within it's >> assigned range. >> PKTDMA also introduced multiple tflows which did not existed in UDMAP. >> >> BCDMA >> It has two types of channels: >> - split channels (tchan/rchan): Similar to UDMAP channels configured in TR >> mode. >> - Block copy channels (bchan): Similar to EDMA or traditional DMA channels, >> they >> can be used for mem2mem type of transfers or to service peripherals not >> accessible via PSI-L by using external triggers for the TR. >> BCDMA channels do not have support for multiple flows >> >> With the introduction of the new DMAs (especially the BCDMA) we also need to >> update the resource manager code to support the second range from sysfw for >> UDMA channels. >> >> The two outstanding change in the series in my view is >> the handling of the DMAs sideband signal of ASEL to select path to provide >> coherency or non coherency. >> >> The smaller one is the device_router_config callback to allow the >> configuration >> of the triggers when BCDMA is servicing a triggering peripheral to solve a >> chicken-egg situation: >> The router needs to know the event number to send which in turn depends on >> the >> channel we got for servicing the peripheral. >> >> Regards, >> Peter >> --- >> Grygorii Strashko (1): >> soc: ti: k3-ringacc: add AM64 DMA rings support. >>
[PATCH] dmaengine: ti: k3-udma-glue: Add new class for glue channels
The dev_release must be provided for a device and in case of the udma glue
layer it is in essence an empty function as the struct containing the
registered device is devm managed.
Reported-by: Vignesh Raghavendra
Signed-off-by: Peter Ujfalusi
---
Hi,
now that we actually have the silicon and the glue layer got into use it was
descovered that we need to have a class with dev_release function for the
devices we create for the physical channels used by the glue layer.
Vinod: I would prefer to send v3 and squash this patch down to the parent.
Regards,
Peter
drivers/dma/ti/k3-udma-glue.c | 19 +++
1 file changed, 19 insertions(+)
diff --git a/drivers/dma/ti/k3-udma-glue.c b/drivers/dma/ti/k3-udma-glue.c
index 2d0b26a7bf78..790027a99c4c 100644
--- a/drivers/dma/ti/k3-udma-glue.c
+++ b/drivers/dma/ti/k3-udma-glue.c
@@ -85,6 +85,16 @@ struct k3_udma_glue_rx_channel {
u32 flows_ready;
};
+static void chan_dev_release(struct device *dev)
+{
+ /* The struct containing the device is devm managed */
+}
+
+static struct class k3_udma_glue_devclass = {
+ .name = "k3_udma_glue_chan",
+ .dev_release= chan_dev_release,
+};
+
#define K3_UDMAX_TDOWN_TIMEOUT_US 1000
static int of_k3_udma_glue_parse(struct device_node *udmax_np,
@@ -286,6 +296,7 @@ struct k3_udma_glue_tx_channel
*k3_udma_glue_request_tx_chn(struct device *dev,
}
tx_chn->udma_tchan_id = xudma_tchan_get_id(tx_chn->udma_tchanx);
+ tx_chn->common.chan_dev.class = _udma_glue_devclass;
tx_chn->common.chan_dev.parent = xudma_get_device(tx_chn->common.udmax);
dev_set_name(_chn->common.chan_dev, "tchan%d-0x%04x",
tx_chn->udma_tchan_id, tx_chn->common.dst_thread);
@@ -903,6 +914,7 @@ k3_udma_glue_request_rx_chn_priv(struct device *dev, const
char *name,
}
rx_chn->udma_rchan_id = xudma_rchan_get_id(rx_chn->udma_rchanx);
+ rx_chn->common.chan_dev.class = _udma_glue_devclass;
rx_chn->common.chan_dev.parent = xudma_get_device(rx_chn->common.udmax);
dev_set_name(_chn->common.chan_dev, "rchan%d-0x%04x",
rx_chn->udma_rchan_id, rx_chn->common.src_thread);
@@ -1033,6 +1045,7 @@ k3_udma_glue_request_remote_rx_chn(struct device *dev,
const char *name,
goto err;
}
+ rx_chn->common.chan_dev.class = _udma_glue_devclass;
rx_chn->common.chan_dev.parent = xudma_get_device(rx_chn->common.udmax);
dev_set_name(_chn->common.chan_dev, "rchan_remote-0x%04x",
rx_chn->common.src_thread);
@@ -1419,3 +1432,9 @@ void k3_udma_glue_rx_cppi5_to_dma_addr(struct
k3_udma_glue_rx_channel *rx_chn,
*addr &= (u64)GENMASK(K3_ADDRESS_ASEL_SHIFT - 1, 0);
}
EXPORT_SYMBOL_GPL(k3_udma_glue_rx_cppi5_to_dma_addr);
+
+static int __init k3_udma_glue_class_init(void)
+{
+ return class_register(_udma_glue_devclass);
+}
+arch_initcall(k3_udma_glue_class_init);
--
Peter
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
Re: [RFC PATCH] ASoC: ak4458: use reset control instead of reset gpio
Hi Viorel,
On 19/11/2020 18.24, Viorel Suman wrote:
> Hi Peter,
>
>> DTS is supposed to look as follows:
>>>
>>> / {
>>> ak4458_reset: gpio-reset {
>>>compatible = "gpio-reset";
>>>reset-gpios = < 4 GPIO_ACTIVE_LOW>;
>>>#reset-cells = <0>;
>>>initially-in-reset;
>>
>> I can not find anything resembling to this in next-20201119.
>> Where is the implementation and documentation for this gpio-reset?
>
> The board schematics is not publicly available; some info may be seen in DTS
> files below:
> https://source.codeaurora.org/external/imx/linux-imx/tree/arch/arm64/boot/dts/freescale/imx8mm-evk.dts?h=imx_5.4.24_2.1.0
> https://source.codeaurora.org/external/imx/linux-imx/tree/arch/arm64/boot/dts/freescale/imx8mm-ab2.dts?h=imx_5.4.24_2.1.0
> https://source.codeaurora.org/external/imx/linux-imx/tree/arch/arm64/boot/dts/freescale/imx8mp-ab2.dts?h=imx_5.4.24_2.1.0
>
> In examples above the GPIO is handled by machine driver - wrong approach
> given that
> it requires machine driver being probed before codec driver.
Right, so this gpio-reset driver is not in mainline. You are adding
support for something which does not exists ;)
>
>>> - ak4458->reset_gpiod = devm_gpiod_get_optional(ak4458->dev,
>> "reset",
>>> - GPIOD_OUT_LOW);
>>> - if (IS_ERR(ak4458->reset_gpiod))
>>> - return PTR_ERR(ak4458->reset_gpiod);
>>> + ak4458->reset = devm_reset_control_get_optional_shared(ak4458-
>>> dev, NULL);
>>> + if (IS_ERR(ak4458->reset))
>>> + return PTR_ERR(ak4458->reset);
>>
>> The binding documentation must be updated and you must support the gpio
>> way as well.
>
> Sure, make sense.
>
>> When I had this discussion around using the reset framework for shared
>> enable and/or reset pins it was suggested that _if_ such a driver makes
>> sense then it should internally handle (by using magic strings) the fallback
>> and work with pre-reset binding.
>
> Thanks, would appreciate if you point me to the discussion you had.
There were few iterations of it when I finally given up, I can quickly
find rfc v2:
https://lkml.org/lkml/2019/10/30/311
Probably in earlier or later series the reset framework was also discussed.
I ended up using GPIOD_FLAGS_BIT_NONEXCLUSIVE in the pcm3168a driver.
https://lkml.org/lkml/2019/11/13/411
- Péter
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
[PATCH v2 1/2] arm64: dts: ti: k3-j7200-som-p0: main_i2c0 have an ioexpander on the SOM
The J7200 SOM have additional io expander which is used to control several
SOM level muxes to make sure that the correct signals are routed to the
correct pin on the SOM <-> CPB connectors.
Signed-off-by: Peter Ujfalusi
Reviewed-by: Vignesh Raghavendra
---
.../dts/ti/k3-j7200-common-proc-board.dts | 11
arch/arm64/boot/dts/ti/k3-j7200-som-p0.dtsi | 26 +++
2 files changed, 26 insertions(+), 11 deletions(-)
diff --git a/arch/arm64/boot/dts/ti/k3-j7200-common-proc-board.dts
b/arch/arm64/boot/dts/ti/k3-j7200-common-proc-board.dts
index 6b3863108571..2721137d8943 100644
--- a/arch/arm64/boot/dts/ti/k3-j7200-common-proc-board.dts
+++ b/arch/arm64/boot/dts/ti/k3-j7200-common-proc-board.dts
@@ -43,13 +43,6 @@ J721E_WKUP_IOPAD(0x0098, PIN_INPUT, 0) /* (L4)
MCU_MDIO0_MDIO */
};
_pmx0 {
- main_i2c0_pins_default: main-i2c0-pins-default {
- pinctrl-single,pins = <
- J721E_IOPAD(0xd4, PIN_INPUT_PULLUP, 0) /* (V3) I2C0_SCL
*/
- J721E_IOPAD(0xd8, PIN_INPUT_PULLUP, 0) /* (W2) I2C0_SDA
*/
- >;
- };
-
main_i2c1_pins_default: main-i2c1-pins-default {
pinctrl-single,pins = <
J721E_IOPAD(0xdc, PIN_INPUT_PULLUP, 3) /* (U3)
ECAP0_IN_APWM_OUT.I2C1_SCL */
@@ -146,10 +139,6 @@ _port1 {
};
_i2c0 {
- pinctrl-names = "default";
- pinctrl-0 = <_i2c0_pins_default>;
- clock-frequency = <40>;
-
exp1: gpio@20 {
compatible = "ti,tca6416";
reg = <0x20>;
diff --git a/arch/arm64/boot/dts/ti/k3-j7200-som-p0.dtsi
b/arch/arm64/boot/dts/ti/k3-j7200-som-p0.dtsi
index fbd17d38f6b6..7b5e9aa0324e 100644
--- a/arch/arm64/boot/dts/ti/k3-j7200-som-p0.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-j7200-som-p0.dtsi
@@ -48,6 +48,15 @@ J721E_WKUP_IOPAD(0x28, PIN_INPUT, 1) /* (A7)
MCU_OSPI0_D7.MCU_HYPERBUS0_DQ7 */
};
};
+_pmx0 {
+ main_i2c0_pins_default: main-i2c0-pins-default {
+ pinctrl-single,pins = <
+ J721E_IOPAD(0xd4, PIN_INPUT_PULLUP, 0) /* (V3) I2C0_SCL
*/
+ J721E_IOPAD(0xd8, PIN_INPUT_PULLUP, 0) /* (W2) I2C0_SDA
*/
+ >;
+ };
+};
+
{
/* OSPI and HBMC are muxed inside FSS, Bootloader will enable
* appropriate node based on board detection
@@ -131,3 +140,20 @@ _cluster10 {
_cluster11 {
status = "disabled";
};
+
+_i2c0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <_i2c0_pins_default>;
+ clock-frequency = <40>;
+
+ exp_som: gpio@21 {
+ compatible = "ti,tca6408";
+ reg = <0x21>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ gpio-line-names = "USB2.0_MUX_SEL", "CANUART_MUX1_SEL0",
+ "CANUART_MUX2_SEL0", "CANUART_MUX_SEL1",
+ "UART/LIN_MUX_SEL",
"TRC_D17/AUDIO_REFCLK_SEL",
+ "GPIO_LIN_EN", "CAN_STB";
+ };
+};
--
Peter
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
[PATCH v2 2/2] arm64: dts: ti: k3-j7200-common-proc-board: Correct the name of io expander on main_i2c1
J7200 main_i2c1 is connected to the i2c bus on the CPB marked as main_i2c3
The i2c1 devices on the CPB are _not_ connected to the SoC, they are not
usable with the J7200 SOM.
Correct the expander name from exp4 to exp3 and at the same time add the
line names as well.
Signed-off-by: Peter Ujfalusi
Reviewed-by: Vignesh Raghavendra
---
.../arm64/boot/dts/ti/k3-j7200-common-proc-board.dts | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/ti/k3-j7200-common-proc-board.dts
b/arch/arm64/boot/dts/ti/k3-j7200-common-proc-board.dts
index 2721137d8943..7110ef3e4092 100644
--- a/arch/arm64/boot/dts/ti/k3-j7200-common-proc-board.dts
+++ b/arch/arm64/boot/dts/ti/k3-j7200-common-proc-board.dts
@@ -154,16 +154,26 @@ exp2: gpio@22 {
};
};
+/*
+ * The j7200 CPB board is identical to the CPB used for J721E, the SOMs can be
+ * swapped on the CPB.
+ *
+ * main_i2c1 of J7200 is connected to the CPB i2c bus labeled as i2c3.
+ * The i2c1 of the CPB (as it is labeled) is not connected to j7200.
+ */
_i2c1 {
pinctrl-names = "default";
pinctrl-0 = <_i2c1_pins_default>;
clock-frequency = <40>;
- exp4: gpio@20 {
+ exp3: gpio@20 {
compatible = "ti,tca6408";
reg = <0x20>;
gpio-controller;
#gpio-cells = <2>;
+ gpio-line-names = "CODEC_RSTz", "CODEC_SPARE1", "UB926_RESETn",
+ "UB926_LOCK", "UB926_PWR_SW_CNTRL",
+ "UB926_TUNER_RESET", "UB926_GPIO_SPARE", "";
};
};
--
Peter
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
[PATCH v2 0/2] arm64: dts: ti: k3-j7200-som/cpb: Correct i2c bus representations
Hi, Changes since v1: - Added REviewed-by from Vignesh - Comment block to explain main_i2c1 connection to CPB The main_i2c0 missed the ioexpander present on the SOM itself to control muxes to route signals to CPB connectors. The main_i2c1 of J7200 is _not_ connected to the i2c1 of CPB, it is connected to i2c3, so the devices on the CPB's i2c1 bus are not avalible, but the ones on the CPB i2c3 are available under the main_i2c1. Add nice line names at the same time to these. Regards, Peter --- Peter Ujfalusi (2): arm64: dts: ti: k3-j7200-som-p0: main_i2c0 have an ioexpander on the SOM arm64: dts: ti: k3-j7200-common-proc-board: Correct the name of io expander on main_i2c1 .../dts/ti/k3-j7200-common-proc-board.dts | 23 arch/arm64/boot/dts/ti/k3-j7200-som-p0.dtsi | 26 +++ 2 files changed, 37 insertions(+), 12 deletions(-) -- Peter Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
Re: [PATCH 2/2] arm64: dts: ti: k3-j7200-common-proc-board: Correct the name of io expander on main_i2c1
On 19/11/2020 18.10, Vignesh Raghavendra wrote:
>
>
> On 11/19/20 6:56 PM, Peter Ujfalusi wrote:
>> J7200 main_i2c1 is connected to the i2c bus on the CPB marked as main_i2c3
>>
>> The i2c1 devices on the CPB are _not_ connected to the SoC, they are not
>> usable with the J7200 SOM.
>>
>> Correct the expander name from exp4 to exp3 and at the same time add the
>> line names as well.
>>
>> Signed-off-by: Peter Ujfalusi
>> ---
>
> Yes, the schematics call this expander as exp3. Thanks for the fix
The CPB is the same for both j721e and j7200 SOMs.
I'll send v2 with a small comment block to explain this.
> Reviewed-by: Vignesh Raghavendra
>
>> arch/arm64/boot/dts/ti/k3-j7200-common-proc-board.dts | 5 -
>> 1 file changed, 4 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/arm64/boot/dts/ti/k3-j7200-common-proc-board.dts
>> b/arch/arm64/boot/dts/ti/k3-j7200-common-proc-board.dts
>> index 2721137d8943..83e043c65f81 100644
>> --- a/arch/arm64/boot/dts/ti/k3-j7200-common-proc-board.dts
>> +++ b/arch/arm64/boot/dts/ti/k3-j7200-common-proc-board.dts
>> @@ -159,11 +159,14 @@ _i2c1 {
>> pinctrl-0 = <_i2c1_pins_default>;
>> clock-frequency = <40>;
>>
>> -exp4: gpio@20 {
>> +exp3: gpio@20 {
>> compatible = "ti,tca6408";
>> reg = <0x20>;
>> gpio-controller;
>> #gpio-cells = <2>;
>> +gpio-line-names = "CODEC_RSTz", "CODEC_SPARE1", "UB926_RESETn",
>> + "UB926_LOCK", "UB926_PWR_SW_CNTRL",
>> + "UB926_TUNER_RESET", "UB926_GPIO_SPARE", "";
>
> I assume these lines have same meaning in J721e and J7200? If so, then
> no issues.
>
>> };
>> };
>>
>>
- Péter
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
[PATCH 2/2] arm64: dts: ti: k3-j7200-common-proc-board: Correct the name of io expander on main_i2c1
J7200 main_i2c1 is connected to the i2c bus on the CPB marked as main_i2c3
The i2c1 devices on the CPB are _not_ connected to the SoC, they are not
usable with the J7200 SOM.
Correct the expander name from exp4 to exp3 and at the same time add the
line names as well.
Signed-off-by: Peter Ujfalusi
---
arch/arm64/boot/dts/ti/k3-j7200-common-proc-board.dts | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/ti/k3-j7200-common-proc-board.dts
b/arch/arm64/boot/dts/ti/k3-j7200-common-proc-board.dts
index 2721137d8943..83e043c65f81 100644
--- a/arch/arm64/boot/dts/ti/k3-j7200-common-proc-board.dts
+++ b/arch/arm64/boot/dts/ti/k3-j7200-common-proc-board.dts
@@ -159,11 +159,14 @@ _i2c1 {
pinctrl-0 = <_i2c1_pins_default>;
clock-frequency = <40>;
- exp4: gpio@20 {
+ exp3: gpio@20 {
compatible = "ti,tca6408";
reg = <0x20>;
gpio-controller;
#gpio-cells = <2>;
+ gpio-line-names = "CODEC_RSTz", "CODEC_SPARE1", "UB926_RESETn",
+ "UB926_LOCK", "UB926_PWR_SW_CNTRL",
+ "UB926_TUNER_RESET", "UB926_GPIO_SPARE", "";
};
};
--
Peter
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
[PATCH 1/2] arm64: dts: ti: k3-j7200-som-p0: main_i2c0 have an ioexpander on the SOM
It is used to control several SOM level muxes to make sure that the correct
signals are routed to the correct pin on the SOM <-> CPB connectors.
Signed-off-by: Peter Ujfalusi
---
.../dts/ti/k3-j7200-common-proc-board.dts | 11
arch/arm64/boot/dts/ti/k3-j7200-som-p0.dtsi | 26 +++
2 files changed, 26 insertions(+), 11 deletions(-)
diff --git a/arch/arm64/boot/dts/ti/k3-j7200-common-proc-board.dts
b/arch/arm64/boot/dts/ti/k3-j7200-common-proc-board.dts
index 6b3863108571..2721137d8943 100644
--- a/arch/arm64/boot/dts/ti/k3-j7200-common-proc-board.dts
+++ b/arch/arm64/boot/dts/ti/k3-j7200-common-proc-board.dts
@@ -43,13 +43,6 @@ J721E_WKUP_IOPAD(0x0098, PIN_INPUT, 0) /* (L4)
MCU_MDIO0_MDIO */
};
_pmx0 {
- main_i2c0_pins_default: main-i2c0-pins-default {
- pinctrl-single,pins = <
- J721E_IOPAD(0xd4, PIN_INPUT_PULLUP, 0) /* (V3) I2C0_SCL
*/
- J721E_IOPAD(0xd8, PIN_INPUT_PULLUP, 0) /* (W2) I2C0_SDA
*/
- >;
- };
-
main_i2c1_pins_default: main-i2c1-pins-default {
pinctrl-single,pins = <
J721E_IOPAD(0xdc, PIN_INPUT_PULLUP, 3) /* (U3)
ECAP0_IN_APWM_OUT.I2C1_SCL */
@@ -146,10 +139,6 @@ _port1 {
};
_i2c0 {
- pinctrl-names = "default";
- pinctrl-0 = <_i2c0_pins_default>;
- clock-frequency = <40>;
-
exp1: gpio@20 {
compatible = "ti,tca6416";
reg = <0x20>;
diff --git a/arch/arm64/boot/dts/ti/k3-j7200-som-p0.dtsi
b/arch/arm64/boot/dts/ti/k3-j7200-som-p0.dtsi
index fbd17d38f6b6..7b5e9aa0324e 100644
--- a/arch/arm64/boot/dts/ti/k3-j7200-som-p0.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-j7200-som-p0.dtsi
@@ -48,6 +48,15 @@ J721E_WKUP_IOPAD(0x28, PIN_INPUT, 1) /* (A7)
MCU_OSPI0_D7.MCU_HYPERBUS0_DQ7 */
};
};
+_pmx0 {
+ main_i2c0_pins_default: main-i2c0-pins-default {
+ pinctrl-single,pins = <
+ J721E_IOPAD(0xd4, PIN_INPUT_PULLUP, 0) /* (V3) I2C0_SCL
*/
+ J721E_IOPAD(0xd8, PIN_INPUT_PULLUP, 0) /* (W2) I2C0_SDA
*/
+ >;
+ };
+};
+
{
/* OSPI and HBMC are muxed inside FSS, Bootloader will enable
* appropriate node based on board detection
@@ -131,3 +140,20 @@ _cluster10 {
_cluster11 {
status = "disabled";
};
+
+_i2c0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <_i2c0_pins_default>;
+ clock-frequency = <40>;
+
+ exp_som: gpio@21 {
+ compatible = "ti,tca6408";
+ reg = <0x21>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ gpio-line-names = "USB2.0_MUX_SEL", "CANUART_MUX1_SEL0",
+ "CANUART_MUX2_SEL0", "CANUART_MUX_SEL1",
+ "UART/LIN_MUX_SEL",
"TRC_D17/AUDIO_REFCLK_SEL",
+ "GPIO_LIN_EN", "CAN_STB";
+ };
+};
--
Peter
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
[PATCH 0/2] arm64: dts: ti: k3-j7200-som/cpb: Correct i2c bus representations
Hi, The main_i2c0 missed the ioexpander present on the SOM itself to control muxes to route signals to CPB connectors. The main_i2c1 of J7200 is _not_ connected to the i2c1 of CPB, it is connected to i2c3, so the devices on the CPB's i2c1 bus are not avalible, but the ones on the CPB i2c3 are available under the main_i2c1. Add nice line names at the same time to these. Regards, Peter --- Peter Ujfalusi (2): arm64: dts: ti: k3-j7200-som-p0: main_i2c0 have an ioexpander on the SOM arm64: dts: ti: k3-j7200-common-proc-board: Correct the name of io expander on main_i2c1 .../dts/ti/k3-j7200-common-proc-board.dts | 16 +++- arch/arm64/boot/dts/ti/k3-j7200-som-p0.dtsi | 26 +++ 2 files changed, 30 insertions(+), 12 deletions(-) -- Peter Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
Re: [RFC PATCH] ASoC: ak4458: use reset control instead of reset gpio
Hi,
On 17/11/2020 0.20, Viorel Suman (OSS) wrote:
> From: Viorel Suman
>
> Using GPIO API seems not a way to go for the case
> when the same reset GPIO is used to control several codecs.
> For a such case we can use the "gpio-reset" driver
> and the "shared" reset API to manage the reset GPIO -
> to deassert the reset when the first codec is powered up
> and assert it when there is no codec in use.
> DTS is supposed to look as follows:
>
> / {
> ak4458_reset: gpio-reset {
>compatible = "gpio-reset";
>reset-gpios = < 4 GPIO_ACTIVE_LOW>;
>#reset-cells = <0>;
>initially-in-reset;
I can not find anything resembling to this in next-20201119.
Where is the implementation and documentation for this gpio-reset?
> };
> };
>
> {
> pca6416: gpio@20 {
>compatible = "ti,tca6416";
>reg = <0x20>;
>gpio-controller;
>#gpio-cells = <2>;
> };
>
> ak4458_1: ak4458@10 {
>compatible = "asahi-kasei,ak4458";
>reg = <0x10>;
>resets = <_reset>;
> };
>
> ak4458_2: ak4458@11 {
>compatible = "asahi-kasei,ak4458";
>reg = <0x11>;
>resets = <_reset>;
> };
>
> ak4458_3: ak4458@12 {
>compatible = "asahi-kasei,ak4458";
>reg = <0x12>;
>resets = <_reset>;
> };
> };
>
> Signed-off-by: Viorel Suman
> ---
> sound/soc/codecs/ak4458.c | 23 +++
> 1 file changed, 11 insertions(+), 12 deletions(-)
>
> diff --git a/sound/soc/codecs/ak4458.c b/sound/soc/codecs/ak4458.c
> index 1010c9ee2e83..f27727cb1382 100644
> --- a/sound/soc/codecs/ak4458.c
> +++ b/sound/soc/codecs/ak4458.c
> @@ -13,6 +13,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -45,7 +46,7 @@ struct ak4458_priv {
> const struct ak4458_drvdata *drvdata;
> struct device *dev;
> struct regmap *regmap;
> - struct gpio_desc *reset_gpiod;
> + struct reset_control *reset;
> struct gpio_desc *mute_gpiod;
> int digfil; /* SSLOW, SD, SLOW bits */
> int fs; /* sampling rate */
> @@ -597,17 +598,17 @@ static struct snd_soc_dai_driver ak4497_dai = {
>
> static void ak4458_power_off(struct ak4458_priv *ak4458)
> {
> - if (ak4458->reset_gpiod) {
> - gpiod_set_value_cansleep(ak4458->reset_gpiod, 0);
> - usleep_range(1000, 2000);
> + if (ak4458->reset) {
> + reset_control_assert(ak4458->reset);
> + msleep(20);
> }
> }
>
> static void ak4458_power_on(struct ak4458_priv *ak4458)
> {
> - if (ak4458->reset_gpiod) {
> - gpiod_set_value_cansleep(ak4458->reset_gpiod, 1);
> - usleep_range(1000, 2000);
> + if (ak4458->reset) {
> + reset_control_deassert(ak4458->reset);
> + msleep(20);
> }
> }
>
> @@ -685,7 +686,6 @@ static int __maybe_unused ak4458_runtime_resume(struct
> device *dev)
> if (ak4458->mute_gpiod)
> gpiod_set_value_cansleep(ak4458->mute_gpiod, 1);
>
> - ak4458_power_off(ak4458);
> ak4458_power_on(ak4458);
>
> regcache_cache_only(ak4458->regmap, false);
> @@ -771,10 +771,9 @@ static int ak4458_i2c_probe(struct i2c_client *i2c)
>
> ak4458->drvdata = of_device_get_match_data(>dev);
>
> - ak4458->reset_gpiod = devm_gpiod_get_optional(ak4458->dev, "reset",
> - GPIOD_OUT_LOW);
> - if (IS_ERR(ak4458->reset_gpiod))
> - return PTR_ERR(ak4458->reset_gpiod);
> + ak4458->reset = devm_reset_control_get_optional_shared(ak4458->dev,
> NULL);
> + if (IS_ERR(ak4458->reset))
> + return PTR_ERR(ak4458->reset);
The binding documentation must be updated and you must support the gpio
way as well.
When I had this discussion around using the reset framework for shared
enable and/or reset pins it was suggested that _if_ such a driver makes
sense then it should internally handle (by using magic strings) the
fallback and work with pre-reset binding.
>
> ak4458->mute_gpiod = devm_gpiod_get_optional(ak4458->dev, "mute",
>GPIOD_OUT_LOW);
>
- Péter
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
[PATCH v2] ARM: dts: keystone-k2g-evm: add HDMI and analog audio data
The board is using McASP2 for both analog (tlv320aic3106) and
HDMI (SiI9022) audio.
12.288MHz oscillator provides the MCLK for both aic3106 and SiI9022.
Signed-off-by: Peter Ujfalusi
---
Hi,
Changes since v1:
- Rename the sii9022_mclk ficed clock to aud_mclk (as it is named in the schema)
and use it within the sound card dai nodes for the codecs.
Regards,
Peter
arch/arm/boot/dts/keystone-k2g-evm.dts | 112 +
1 file changed, 112 insertions(+)
diff --git a/arch/arm/boot/dts/keystone-k2g-evm.dts
b/arch/arm/boot/dts/keystone-k2g-evm.dts
index 8b3d64c913d8..14e26a4fd62a 100644
--- a/arch/arm/boot/dts/keystone-k2g-evm.dts
+++ b/arch/arm/boot/dts/keystone-k2g-evm.dts
@@ -46,6 +46,14 @@ vcc1v8_ldo1_reg: fixedregulator-vcc1v8-ldo1 {
regulator-always-on;
};
+ vcc1v8_ldo2_reg: fixedregulator-vcc1v8-ldo2 {
+ compatible = "regulator-fixed";
+ regulator-name = "ldo2";
+ regulator-min-microvolt = <180>;
+ regulator-max-microvolt = <180>;
+ regulator-always-on;
+ };
+
hdmi: connector {
compatible = "hdmi-connector";
label = "hdmi";
@@ -58,6 +66,57 @@ hdmi_connector_in: endpoint {
};
};
};
+
+ aud_mclk: aud_mclk {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <12288000>;
+ };
+
+ sound0: sound@0 {
+ compatible = "simple-audio-card";
+ simple-audio-card,name = "K2G-EVM";
+ simple-audio-card,widgets =
+ "Headphone", "Headphone Jack",
+ "Line", "Line In";
+ simple-audio-card,routing =
+ "Headphone Jack", "HPLOUT",
+ "Headphone Jack", "HPROUT",
+ "LINE1L", "Line In",
+ "LINE1R", "Line In";
+
+ simple-audio-card,dai-link@0 {
+ format = "i2s";
+ bitclock-master = <_0_master>;
+ frame-master = <_0_master>;
+ sound0_0_master: cpu {
+ sound-dai = <>;
+ clocks = <_clks 0x6 1>;
+ system-clock-direction-out;
+ };
+
+ codec {
+ sound-dai = <>;
+ clocks = <_mclk>;
+ };
+ };
+
+ simple-audio-card,dai-link@1 {
+ format = "i2s";
+ bitclock-master = <_1_master>;
+ frame-master = <_1_master>;
+ sound0_1_master: cpu {
+ sound-dai = <>;
+ clocks = <_clks 0x6 1>;
+ system-clock-direction-out;
+ };
+
+ codec {
+ sound-dai = <>;
+ clocks = <_mclk>;
+ };
+ };
+ };
};
_pinctrl {
@@ -214,6 +273,15 @@ K2G_CORE_IOPAD(0x10e4) (BUFFER_CLASS_B | PULL_DISABLE |
MUX_MODE0) /* dssde.dssd
K2G_CORE_IOPAD(0x10e8) (BUFFER_CLASS_B | PULL_DISABLE |
MUX_MODE0) /* dssfid.dssfid */
>;
};
+
+ mcasp2_pins: pinmux_mcasp2_pins {
+ pinctrl-single,pins = <
+ K2G_CORE_IOPAD(0x1234) (BUFFER_CLASS_B | PIN_PULLDOWN |
MUX_MODE4) /* pr0_pru_gpo2.mcasp2_axr2 */
+ K2G_CORE_IOPAD(0x1238) (BUFFER_CLASS_B | PIN_PULLDOWN |
MUX_MODE4) /* pr0_pru_gpo3.mcasp2_axr3 */
+ K2G_CORE_IOPAD(0x1254) (BUFFER_CLASS_B | PIN_PULLDOWN |
MUX_MODE4) /* pr0_pru_gpo10.mcasp2_afsx */
+ K2G_CORE_IOPAD(0x125c) (BUFFER_CLASS_B | PIN_PULLDOWN |
MUX_MODE4) /* pr0_pru_gpo12.mcasp2_aclkx */
+ >;
+ };
};
{
@@ -423,6 +491,10 @@ sii9022: sii9022@3b {
compatible = "sil,sii9022";
reg = <0x3b>;
+ sil,i2s-data-lanes = < 0 >;
+ clocks = <_mclk>;
+ clock-names = "mclk";
+
ports {
#address-cells = <1>;
#size-cells = <0>;
@@ -444,6 +516,19 @@ sii9022_out: endpoint {
};
};
};
+
+ tlv320a
Re: [PATCH] ARM: dts: keystone-k2g-evm: add HDMI and analog audio data
Hi,
On 17/11/2020 12.17, Peter Ujfalusi wrote:
> The board is using McASP2 for both analog (tlv320aic3106) and
> HDMI (SiI9022) audio.
>
> Signed-off-by: Peter Ujfalusi
> ---
> arch/arm/boot/dts/keystone-k2g-evm.dts | 112 +
> 1 file changed, 112 insertions(+)
>
> diff --git a/arch/arm/boot/dts/keystone-k2g-evm.dts
> b/arch/arm/boot/dts/keystone-k2g-evm.dts
> index 8b3d64c913d8..4d7e3514a3a7 100644
> --- a/arch/arm/boot/dts/keystone-k2g-evm.dts
> +++ b/arch/arm/boot/dts/keystone-k2g-evm.dts
> @@ -46,6 +46,14 @@ vcc1v8_ldo1_reg: fixedregulator-vcc1v8-ldo1 {
> regulator-always-on;
> };
>
> + vcc1v8_ldo2_reg: fixedregulator-vcc1v8-ldo2 {
> + compatible = "regulator-fixed";
> + regulator-name = "ldo2";
> + regulator-min-microvolt = <180>;
> + regulator-max-microvolt = <180>;
> + regulator-always-on;
> + };
> +
> hdmi: connector {
> compatible = "hdmi-connector";
> label = "hdmi";
> @@ -58,6 +66,57 @@ hdmi_connector_in: endpoint {
> };
> };
> };
> +
> + sound0: sound@0 {
> + compatible = "simple-audio-card";
> + simple-audio-card,name = "K2G-EVM";
> + simple-audio-card,widgets =
> + "Headphone", "Headphone Jack",
> + "Line", "Line In";
> + simple-audio-card,routing =
> + "Headphone Jack", "HPLOUT",
> + "Headphone Jack", "HPROUT",
> + "LINE1L", "Line In",
> + "LINE1R", "Line In";
> +
> + simple-audio-card,dai-link@0 {
> + format = "i2s";
> + bitclock-master = <_0_master>;
> + frame-master = <_0_master>;
> + sound0_0_master: cpu {
> + sound-dai = <>;
> + clocks = <_clks 0x6 1>;
> + system-clock-direction-out;
> + };
> +
> + codec {
> + sound-dai = <>;
> + system-clock-frequency = <12288000>;
I think it would be better to use:
clocks = <_mclk>;
> + };
> + };
> +
> + simple-audio-card,dai-link@1 {
> + format = "i2s";
> + bitclock-master = <_1_master>;
> + frame-master = <_1_master>;
> + sound0_1_master: cpu {
> + sound-dai = <>;
> + clocks = <_clks 0x6 1>;
> + system-clock-direction-out;
> + };
> +
> + codec {
> + sound-dai = <>;
> + system-clock-frequency = <12288000>;
and here as well:
clocks = <_mclk>;
> + };
> + };
> + };
> +
> + sii9022_mclk: sii9022_mclk {
and rename the fixed clock to aud_mclk as the same clock is connected to
both aic3106 and SiI9022
> + compatible = "fixed-clock";
> + #clock-cells = <0>;
> + clock-frequency = <12288000>;
> + };
> };
>
> _pinctrl {
> @@ -214,6 +273,15 @@ K2G_CORE_IOPAD(0x10e4) (BUFFER_CLASS_B | PULL_DISABLE |
> MUX_MODE0) /* dssde.dssd
> K2G_CORE_IOPAD(0x10e8) (BUFFER_CLASS_B | PULL_DISABLE |
> MUX_MODE0) /* dssfid.dssfid */
> >;
> };
> +
> + mcasp2_pins: pinmux_mcasp2_pins {
> + pinctrl-single,pins = <
> + K2G_CORE_IOPAD(0x1234) (BUFFER_CLASS_B | PIN_PULLDOWN |
> MUX_MODE4) /* pr0_pru_gpo2.mcasp2_axr2 */
> + K2G_CORE_IOPAD(0x1238) (BUFFER_CLASS_B | PIN_PULLDOWN |
> MUX_MODE4) /* pr0_pru_gpo3.mcasp2_axr3 */
> + K2G_CORE_IOPAD(0x1254) (BUFFER_CLASS_B | PIN_PULLDOWN |
> MUX_MODE4) /* pr0_pru_gpo10.mcasp2_afsx */
> + K2G_CORE_IOPAD(0x125c) (BUFFER_CLASS_B | PIN_PULLDOWN |
> MUX_MODE4) /* pr0_pru_gpo12.mcasp2_aclkx */
> + >;
> + };
> };
>
> {
>
[PATCH v2 18/19] dmaengine: ti: k3-udma: Initial support for K3 PKTDMA
One of the DMAs introduced with AM64 is the Packet DMA (PKTDMA).
It serves similar purpose as K3 UDMAP channels in packet mode, but with
notable differences, like tflow support and channels being allocated to
service specific peripherals.
The rings for the PKTDMA is integrated within the DMA itself instead of
using rings from the general purpose ringacc.
PKTDMA can be used to service PSI-L peripherals, similarly to
K3 UDMA channels.
Most of the driver code can be reused for PKTDMA tchan/rchan support but
new setup and allocation functions are needed to handle the differences
between the DMAs.
Signed-off-by: Peter Ujfalusi
---
drivers/dma/ti/k3-udma-private.c | 9 +
drivers/dma/ti/k3-udma.c | 545 +--
drivers/dma/ti/k3-udma.h | 4 +
3 files changed, 533 insertions(+), 25 deletions(-)
diff --git a/drivers/dma/ti/k3-udma-private.c b/drivers/dma/ti/k3-udma-private.c
index c9fb1d832581..87cbcfe96d5f 100644
--- a/drivers/dma/ti/k3-udma-private.c
+++ b/drivers/dma/ti/k3-udma-private.c
@@ -82,6 +82,9 @@ EXPORT_SYMBOL(xudma_free_gp_rflow_range);
bool xudma_rflow_is_gp(struct udma_dev *ud, int id)
{
+ if (!ud->rflow_gp_map)
+ return false;
+
return !test_bit(id, ud->rflow_gp_map);
}
EXPORT_SYMBOL(xudma_rflow_is_gp);
@@ -113,6 +116,12 @@ void xudma_rflow_put(struct udma_dev *ud, struct
udma_rflow *p)
}
EXPORT_SYMBOL(xudma_rflow_put);
+int xudma_get_rflow_ring_offset(struct udma_dev *ud)
+{
+ return ud->tflow_cnt;
+}
+EXPORT_SYMBOL(xudma_get_rflow_ring_offset);
+
#define XUDMA_GET_RESOURCE_ID(res) \
int xudma_##res##_get_id(struct udma_##res *p) \
{ \
diff --git a/drivers/dma/ti/k3-udma.c b/drivers/dma/ti/k3-udma.c
index 0dc3430fea40..87157cbae1b8 100644
--- a/drivers/dma/ti/k3-udma.c
+++ b/drivers/dma/ti/k3-udma.c
@@ -59,6 +59,7 @@ struct udma_chan;
enum k3_dma_type {
DMA_TYPE_UDMA = 0,
DMA_TYPE_BCDMA,
+ DMA_TYPE_PKTDMA,
};
enum udma_mmr {
@@ -82,6 +83,8 @@ struct udma_tchan {
int id;
struct k3_ring *t_ring; /* Transmit ring */
struct k3_ring *tc_ring; /* Transmit Completion ring */
+ int tflow_id; /* applicable only for PKTDMA */
+
};
#define udma_bchan udma_tchan
@@ -109,6 +112,10 @@ struct udma_oes_offsets {
u32 bcdma_tchan_ring;
u32 bcdma_rchan_data;
u32 bcdma_rchan_ring;
+
+ /* PKTDMA Output Event Offsets */
+ u32 pktdma_tchan_flow;
+ u32 pktdma_rchan_flow;
};
#define UDMA_FLAG_PDMA_ACC32 BIT(0)
@@ -179,12 +186,14 @@ struct udma_dev {
int echan_cnt;
int rchan_cnt;
int rflow_cnt;
+ int tflow_cnt;
unsigned long *bchan_map;
unsigned long *tchan_map;
unsigned long *rchan_map;
unsigned long *rflow_gp_map;
unsigned long *rflow_gp_map_allocated;
unsigned long *rflow_in_use;
+ unsigned long *tflow_map;
struct udma_bchan *bchans;
struct udma_tchan *tchans;
@@ -249,6 +258,11 @@ struct udma_chan_config {
u32 tr_trigger_type;
+ /* PKDMA mapped channel */
+ int mapped_channel_id;
+ /* PKTDMA default tflow or rflow for mapped channel */
+ int default_flow_id;
+
enum dma_transfer_direction dir;
};
@@ -426,6 +440,8 @@ static void udma_reset_uchan(struct udma_chan *uc)
{
memset(>config, 0, sizeof(uc->config));
uc->config.remote_thread_id = -1;
+ uc->config.mapped_channel_id = -1;
+ uc->config.default_flow_id = -1;
uc->state = UDMA_CHAN_IS_IDLE;
}
@@ -815,10 +831,16 @@ static void udma_start_desc(struct udma_chan *uc)
{
struct udma_chan_config *ucc = >config;
- if (ucc->pkt_mode && (uc->cyclic || ucc->dir == DMA_DEV_TO_MEM)) {
+ if (uc->ud->match_data->type == DMA_TYPE_UDMA && ucc->pkt_mode &&
+ (uc->cyclic || ucc->dir == DMA_DEV_TO_MEM)) {
int i;
- /* Push all descriptors to ring for packet mode cyclic or RX */
+ /*
+* UDMA only: Push all descriptors to ring for packet mode
+* cyclic or RX
+* PKTDMA supports pre-linked descriptor and cyclic is not
+* supported
+*/
for (i = 0; i < uc->desc->sglen; i++)
udma_push_to_ring(uc, i);
} else {
@@ -1248,10 +1270,12 @@ static struct udma_rflow *__udma_get_rflow(struct
udma_dev *ud, int id)
if (test_bit(id, ud->rflow_in_use))
return ERR_PTR(-ENOENT);
- /* GP rflow has to be allocated first */
- if (!test_bit(id, ud->rflow_gp_map) &&
- !test_bit(id, ud->rflow_gp_map_allocated))
- ret
[PATCH v2 16/19] dmaengine: ti: k3-udma: Initial support for K3 BCDMA
One of the DMAs introduced with AM64 is the Block Copy DMA (BCDMA).
It serves similar purpose as K3 UDMAP channels in TR mode.
The rings for the BCDMA is integrated within the DMA itself instead of
using rings from the general purpose ringacc.
A BCDMA have two different type of channels:
- Block Copy Channels (bchan)
- Split Channels (tchan and rchan)
tchan and rchan can be used to service PSI-L peripherals, similarly to
K3 UDMA channels.
bchan can be only used for block copy operation (TR type15) like the
paired K3 UDMA tchan/rchan configured in block copy mode.
bchans can be also used to service peripherals directly if an external
trigger is selected for the channel.
Most of the driver code can be reused for BCDMA bchan/tchan/rchan support
but new setup and allocation functions are needed to handle the
differences between the DMAs.
Signed-off-by: Peter Ujfalusi
---
drivers/dma/ti/k3-udma.c | 1384 ++
drivers/dma/ti/k3-udma.h | 12 +-
2 files changed, 1245 insertions(+), 151 deletions(-)
diff --git a/drivers/dma/ti/k3-udma.c b/drivers/dma/ti/k3-udma.c
index b89afa602532..f327d436f8ad 100644
--- a/drivers/dma/ti/k3-udma.c
+++ b/drivers/dma/ti/k3-udma.c
@@ -26,6 +26,7 @@
#include
#include
#include
+#include
#include
#include "../virt-dma.h"
@@ -55,14 +56,25 @@ struct udma_static_tr {
struct udma_chan;
+enum k3_dma_type {
+ DMA_TYPE_UDMA = 0,
+ DMA_TYPE_BCDMA,
+};
+
enum udma_mmr {
MMR_GCFG = 0,
+ MMR_BCHANRT,
MMR_RCHANRT,
MMR_TCHANRT,
MMR_LAST,
};
-static const char * const mmr_names[] = { "gcfg", "rchanrt", "tchanrt" };
+static const char * const mmr_names[] = {
+ [MMR_GCFG] = "gcfg",
+ [MMR_BCHANRT] = "bchanrt",
+ [MMR_RCHANRT] = "rchanrt",
+ [MMR_TCHANRT] = "tchanrt",
+};
struct udma_tchan {
void __iomem *reg_rt;
@@ -72,6 +84,8 @@ struct udma_tchan {
struct k3_ring *tc_ring; /* Transmit Completion ring */
};
+#define udma_bchan udma_tchan
+
struct udma_rflow {
int id;
struct k3_ring *fd_ring; /* Free Descriptor ring */
@@ -84,11 +98,25 @@ struct udma_rchan {
int id;
};
+struct udma_oes_offsets {
+ /* K3 UDMA Output Event Offset */
+ u32 udma_rchan;
+
+ /* BCDMA Output Event Offsets */
+ u32 bcdma_bchan_data;
+ u32 bcdma_bchan_ring;
+ u32 bcdma_tchan_data;
+ u32 bcdma_tchan_ring;
+ u32 bcdma_rchan_data;
+ u32 bcdma_rchan_ring;
+};
+
#define UDMA_FLAG_PDMA_ACC32 BIT(0)
#define UDMA_FLAG_PDMA_BURST BIT(1)
#define UDMA_FLAG_TDTYPE BIT(2)
struct udma_match_data {
+ enum k3_dma_type type;
u32 psil_base;
bool enable_memcpy_support;
u32 flags;
@@ -96,7 +124,8 @@ struct udma_match_data {
};
struct udma_soc_data {
- u32 rchan_oes_offset;
+ struct udma_oes_offsets oes;
+ u32 bcdma_trigger_event_offset;
};
struct udma_hwdesc {
@@ -139,16 +168,19 @@ struct udma_dev {
struct udma_rx_flush rx_flush;
+ int bchan_cnt;
int tchan_cnt;
int echan_cnt;
int rchan_cnt;
int rflow_cnt;
+ unsigned long *bchan_map;
unsigned long *tchan_map;
unsigned long *rchan_map;
unsigned long *rflow_gp_map;
unsigned long *rflow_gp_map_allocated;
unsigned long *rflow_in_use;
+ struct udma_bchan *bchans;
struct udma_tchan *tchans;
struct udma_rchan *rchans;
struct udma_rflow *rflows;
@@ -156,6 +188,7 @@ struct udma_dev {
struct udma_chan *channels;
u32 psil_base;
u32 atype;
+ u32 asel;
};
struct udma_desc {
@@ -200,6 +233,7 @@ struct udma_chan_config {
bool notdpkt; /* Suppress sending TDC packet */
int remote_thread_id;
u32 atype;
+ u32 asel;
u32 src_thread;
u32 dst_thread;
enum psil_endpoint_type ep_type;
@@ -207,6 +241,8 @@ struct udma_chan_config {
bool enable_burst;
enum udma_tp_level channel_tpl; /* Channel Throughput Level */
+ u32 tr_trigger_type;
+
enum dma_transfer_direction dir;
};
@@ -214,11 +250,13 @@ struct udma_chan {
struct virt_dma_chan vc;
struct dma_slave_config cfg;
struct udma_dev *ud;
+ struct device *dma_dev;
struct udma_desc *desc;
struct udma_desc *terminated_desc;
struct udma_static_tr static_tr;
char *name;
+ struct udma_bchan *bchan;
struct udma_tchan *tchan;
struct udma_rchan *rchan;
struct udma_rflow *rflow;
@@ -354,6 +392,30 @@ static int navss_psil_unpair(struct udma_dev *ud, u32
src_thread,
src_thread, dst_thread);
}
+static void k3_configure_chan_coherency(struct dma_chan *chan, u32
[PATCH v2 00/19] dmaengine/soc: k3-udma: Add support for BCDMA and PKTDMA
Hi, The series have build dependency on ti_sci/soc series (v2): https://lore.kernel.org/lkml/20201008115224.1591-1-peter.ujfal...@ti.com/ Santosh kindly created immutable branch holdinf the series: git://git.kernel.org/pub/scm/linux/kernel/git/ssantosh/linux-keystone.git for_5.11/drivers-soc The unmapped event handling in INTA is already mainline. Changes since v1: - Both DT binding document has been updated to address all comments and suggestions from Rob, all checks are passing on them - included new patch to fix the normal channel start offset when ultra-high capacity channels are available for the UDMA and updated the BCDMA/PKTDMA patches along the same line - Re-arranged the patches for Vinod so that the preparational patches and fixes can be picked up separately (they still have dependency on Santosh's branch): patch 1-5: Fixes and new features for existing devices using UDMA, but the the BCDMA/PKTDMA support is building on top of these. Build dependency on Santosh's branch patch 6: Optional second stage router configuration callback support in core patch 7-9: Per channel coherency support in core and use it in dmatest. patch 10-: Initial AM64 BCDMA and PKTDMA support The DMSS introduced within AM64 as a simplified Data movement engine is built on similar grounds as the K3 NAVSS and UDMAP, but with significant architectural changes. - Rings are built into the DMAs The DMAs no longer use the general purpose ringacc, all rings has been moved inside of the DMAs. The new rings within the DMAs are simplified to be dual directional compared to the uni-directional rings in ringacc. There is no more of a concept of generic purpose rings, all rings are assigned to specific channels or flows. - Per channel coherency support The DMAs use the 'ASEL' bits to select data and configuration fetch path. The ASEL bits are placed at the unused parts of any address field used by the DMAs (pointers to descriptors, addresses in descriptors, ring base addresses). The ASEL is not part of the address (the DMAs can address 48bits). Individual channels can be configured to be coherent (via ACP port) or non coherent individually by configuring the ASEL to appropriate value. - Two different DMAs (well, three actually) PKTDMA Similar to UDMAP channels configured in packet mode. The flow configuration of the channels has changed significantly in a way that each channel have at least one flow assigned at design time and each flow is directly mapped to corresponding ring. When multiple flows are set, the channel can only use the flows within it's assigned range. PKTDMA also introduced multiple tflows which did not existed in UDMAP. BCDMA It has two types of channels: - split channels (tchan/rchan): Similar to UDMAP channels configured in TR mode. - Block copy channels (bchan): Similar to EDMA or traditional DMA channels, they can be used for mem2mem type of transfers or to service peripherals not accessible via PSI-L by using external triggers for the TR. BCDMA channels do not have support for multiple flows With the introduction of the new DMAs (especially the BCDMA) we also need to update the resource manager code to support the second range from sysfw for UDMA channels. The two outstanding change in the series in my view is the handling of the DMAs sideband signal of ASEL to select path to provide coherency or non coherency. The smaller one is the device_router_config callback to allow the configuration of the triggers when BCDMA is servicing a triggering peripheral to solve a chicken-egg situation: The router needs to know the event number to send which in turn depends on the channel we got for servicing the peripheral. Regards, Peter --- Grygorii Strashko (1): soc: ti: k3-ringacc: add AM64 DMA rings support. Peter Ujfalusi (17): dmaengine: ti: k3-udma: Correct normal channel offset when uchan_cnt is not 0 dmaengine: ti: k3-udma: Wait for peer teardown completion if supported dmaengine: ti: k3-udma: Add support for second resource range from sysfw dmaengine: ti: k3-udma-glue: Add function to get device pointer for DMA API dmaengine: ti: k3-udma-glue: Configure the dma_dev for rings dmaengine: of-dma: Add support for optional router configuration callback dmaengine: Add support for per channel coherency handling dmaengine: doc: client: Update for dmaengine_get_dma_device() usage dmaengine: dmatest: Use dmaengine_get_dma_device dt-bindings: dma: ti: Add document for K3 BCDMA dt-bindings: dma: ti: Add document for K3 PKTDMA dmaengine: ti: k3-psil: Extend psil_endpoint_config for K3 PKTDMA dmaengine: ti: k3-psil: Add initial map for AM64 dmaengine: ti: Add support for k3 event routers dmaengine: ti: k3-udma: Initial support for K3 BCDMA dmaengine: ti: k3-udma: Add support for BCDMA channel TPL handling dmaengine: ti: k3-udma: Initial support for K3 PKTDMA Vignesh Raghavendra (1): dmaengine: ti: k3-udma-glue: Add
[PATCH v2 04/19] dmaengine: ti: k3-udma-glue: Add function to get device pointer for DMA API
Glue layer users should use the device of the DMA for DMA mapping and
allocations as it is the DMA which accesses to descriptors and buffers,
not the clients
Signed-off-by: Peter Ujfalusi
---
drivers/dma/ti/k3-udma-glue.c| 14 ++
drivers/dma/ti/k3-udma-private.c | 6 ++
drivers/dma/ti/k3-udma.h | 1 +
include/linux/dma/k3-udma-glue.h | 4
4 files changed, 25 insertions(+)
diff --git a/drivers/dma/ti/k3-udma-glue.c b/drivers/dma/ti/k3-udma-glue.c
index dfb65e382ab9..29d1524d1916 100644
--- a/drivers/dma/ti/k3-udma-glue.c
+++ b/drivers/dma/ti/k3-udma-glue.c
@@ -493,6 +493,13 @@ int k3_udma_glue_tx_get_irq(struct k3_udma_glue_tx_channel
*tx_chn)
}
EXPORT_SYMBOL_GPL(k3_udma_glue_tx_get_irq);
+struct device *
+ k3_udma_glue_tx_get_dma_device(struct k3_udma_glue_tx_channel *tx_chn)
+{
+ return xudma_get_device(tx_chn->common.udmax);
+}
+EXPORT_SYMBOL_GPL(k3_udma_glue_tx_get_dma_device);
+
static int k3_udma_glue_cfg_rx_chn(struct k3_udma_glue_rx_channel *rx_chn)
{
const struct udma_tisci_rm *tisci_rm = rx_chn->common.tisci_rm;
@@ -1201,3 +1208,10 @@ int k3_udma_glue_rx_get_irq(struct
k3_udma_glue_rx_channel *rx_chn,
return flow->virq;
}
EXPORT_SYMBOL_GPL(k3_udma_glue_rx_get_irq);
+
+struct device *
+ k3_udma_glue_rx_get_dma_device(struct k3_udma_glue_rx_channel *rx_chn)
+{
+ return xudma_get_device(rx_chn->common.udmax);
+}
+EXPORT_SYMBOL_GPL(k3_udma_glue_rx_get_dma_device);
diff --git a/drivers/dma/ti/k3-udma-private.c b/drivers/dma/ti/k3-udma-private.c
index 8563a392f30b..c9fb1d832581 100644
--- a/drivers/dma/ti/k3-udma-private.c
+++ b/drivers/dma/ti/k3-udma-private.c
@@ -50,6 +50,12 @@ struct udma_dev *of_xudma_dev_get(struct device_node *np,
const char *property)
}
EXPORT_SYMBOL(of_xudma_dev_get);
+struct device *xudma_get_device(struct udma_dev *ud)
+{
+ return ud->dev;
+}
+EXPORT_SYMBOL(xudma_get_device);
+
u32 xudma_dev_get_psil_base(struct udma_dev *ud)
{
return ud->psil_base;
diff --git a/drivers/dma/ti/k3-udma.h b/drivers/dma/ti/k3-udma.h
index 09c4529e013d..d1cace0cb43b 100644
--- a/drivers/dma/ti/k3-udma.h
+++ b/drivers/dma/ti/k3-udma.h
@@ -112,6 +112,7 @@ int xudma_navss_psil_unpair(struct udma_dev *ud, u32
src_thread,
u32 dst_thread);
struct udma_dev *of_xudma_dev_get(struct device_node *np, const char
*property);
+struct device *xudma_get_device(struct udma_dev *ud);
void xudma_dev_put(struct udma_dev *ud);
u32 xudma_dev_get_psil_base(struct udma_dev *ud);
struct udma_tisci_rm *xudma_dev_get_tisci_rm(struct udma_dev *ud);
diff --git a/include/linux/dma/k3-udma-glue.h b/include/linux/dma/k3-udma-glue.h
index 5eb34ad973a7..d7c12f31377c 100644
--- a/include/linux/dma/k3-udma-glue.h
+++ b/include/linux/dma/k3-udma-glue.h
@@ -41,6 +41,8 @@ void k3_udma_glue_reset_tx_chn(struct k3_udma_glue_tx_channel
*tx_chn,
u32 k3_udma_glue_tx_get_hdesc_size(struct k3_udma_glue_tx_channel *tx_chn);
u32 k3_udma_glue_tx_get_txcq_id(struct k3_udma_glue_tx_channel *tx_chn);
int k3_udma_glue_tx_get_irq(struct k3_udma_glue_tx_channel *tx_chn);
+struct device *
+ k3_udma_glue_tx_get_dma_device(struct k3_udma_glue_tx_channel *tx_chn);
enum {
K3_UDMA_GLUE_SRC_TAG_LO_KEEP = 0,
@@ -130,5 +132,7 @@ int k3_udma_glue_rx_flow_enable(struct
k3_udma_glue_rx_channel *rx_chn,
u32 flow_idx);
int k3_udma_glue_rx_flow_disable(struct k3_udma_glue_rx_channel *rx_chn,
u32 flow_idx);
+struct device *
+ k3_udma_glue_rx_get_dma_device(struct k3_udma_glue_rx_channel *rx_chn);
#endif /* K3_UDMA_GLUE_H_ */
--
Peter
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
[PATCH v2 17/19] dmaengine: ti: k3-udma: Add support for BCDMA channel TPL handling
Unlike UDMAP the BCDMA defines the channel TPL levels per channel type.
In UDMAP the number of high and ultra-high channels applies to both tchan
and rchan.
BCDMA defines the TPL per channel types: bchan, tchan and rchan can have
different number of high and ultra-high channels.
In order to support BCDMA channel TPL we need to move the tpl information
as per channel type property for the DMAs.
Signed-off-by: Peter Ujfalusi
---
drivers/dma/ti/k3-udma.c | 117 ++-
drivers/dma/ti/k3-udma.h | 6 ++
2 files changed, 85 insertions(+), 38 deletions(-)
diff --git a/drivers/dma/ti/k3-udma.c b/drivers/dma/ti/k3-udma.c
index f327d436f8ad..0dc3430fea40 100644
--- a/drivers/dma/ti/k3-udma.c
+++ b/drivers/dma/ti/k3-udma.c
@@ -146,6 +146,11 @@ struct udma_rx_flush {
dma_addr_t buffer_paddr;
};
+struct udma_tpl {
+ u8 levels;
+ u32 start_idx[3];
+};
+
struct udma_dev {
struct dma_device ddev;
struct device *dev;
@@ -153,8 +158,9 @@ struct udma_dev {
const struct udma_match_data *match_data;
const struct udma_soc_data *soc_data;
- u8 tpl_levels;
- u32 tpl_start_idx[3];
+ struct udma_tpl bchan_tpl;
+ struct udma_tpl tchan_tpl;
+ struct udma_tpl rchan_tpl;
size_t desc_align; /* alignment to use for descriptors */
@@ -1276,10 +1282,10 @@ static struct udma_##res *__udma_reserve_##res(struct
udma_dev *ud, \
} else {\
int start; \
\
- if (tpl >= ud->tpl_levels) \
- tpl = ud->tpl_levels - 1; \
+ if (tpl >= ud->res##_tpl.levels)\
+ tpl = ud->res##_tpl.levels - 1; \
\
- start = ud->tpl_start_idx[tpl]; \
+ start = ud->res##_tpl.start_idx[tpl]; \
\
id = find_next_zero_bit(ud->res##_map, ud->res##_cnt, \
start); \
@@ -1292,29 +1298,14 @@ static struct udma_##res *__udma_reserve_##res(struct
udma_dev *ud, \
return >res##s[id]; \
}
+UDMA_RESERVE_RESOURCE(bchan);
UDMA_RESERVE_RESOURCE(tchan);
UDMA_RESERVE_RESOURCE(rchan);
-static struct udma_bchan *__bcdma_reserve_bchan(struct udma_dev *ud, int id)
-{
- if (id >= 0) {
- if (test_bit(id, ud->bchan_map)) {
- dev_err(ud->dev, "bchan%d is in use\n", id);
- return ERR_PTR(-ENOENT);
- }
- } else {
- id = find_next_zero_bit(ud->bchan_map, ud->bchan_cnt, 0);
- if (id == ud->bchan_cnt)
- return ERR_PTR(-ENOENT);
- }
-
- set_bit(id, ud->bchan_map);
- return >bchans[id];
-}
-
static int bcdma_get_bchan(struct udma_chan *uc)
{
struct udma_dev *ud = uc->ud;
+ enum udma_tp_level tpl;
if (uc->bchan) {
dev_dbg(ud->dev, "chan%d: already have bchan%d allocated\n",
@@ -1322,7 +1313,16 @@ static int bcdma_get_bchan(struct udma_chan *uc)
return 0;
}
- uc->bchan = __bcdma_reserve_bchan(ud, -1);
+ /*
+* Use normal channels for peripherals, and highest TPL channel for
+* mem2mem
+*/
+ if (uc->config.tr_trigger_type)
+ tpl = 0;
+ else
+ tpl = ud->bchan_tpl.levels - 1;
+
+ uc->bchan = __udma_reserve_bchan(ud, tpl, -1);
if (IS_ERR(uc->bchan))
return PTR_ERR(uc->bchan);
@@ -1384,8 +1384,11 @@ static int udma_get_chan_pair(struct udma_chan *uc)
/* Can be optimized, but let's have it like this for now */
end = min(ud->tchan_cnt, ud->rchan_cnt);
- /* Try to use the highest TPL channel pair for MEM_TO_MEM channels */
- chan_id = ud->tpl_start_idx[ud->tpl_levels - 1];
+ /*
+* Try to use the highest TPL channel pair for MEM_TO_MEM channels
+* Note: in UDMAP the channel TPL is symmetric between tchan and rchan
+*/
+ chan_id = ud->tchan_tpl.start_idx[ud->tchan_tpl.levels - 1];
for (; chan_id < end; chan_id++) {
if (!test_bit(chan_id, ud->tchan_map) &&
!test_bit(chan_id, ud->rchan_map))
@@ -4036,23 +4039,27 @@ static int udma_setup_resources(struct udma_dev *ud)
cap3 = udma_read(
[PATCH v2 13/19] dmaengine: ti: k3-psil: Add initial map for AM64
Add initial PSI-L map file for AM64.
Signed-off-by: Peter Ujfalusi
---
drivers/dma/ti/Makefile | 3 +-
drivers/dma/ti/k3-psil-am64.c | 75 +++
drivers/dma/ti/k3-psil-priv.h | 1 +
drivers/dma/ti/k3-psil.c | 1 +
4 files changed, 79 insertions(+), 1 deletion(-)
create mode 100644 drivers/dma/ti/k3-psil-am64.c
diff --git a/drivers/dma/ti/Makefile b/drivers/dma/ti/Makefile
index 0c67254caee6..bd496efadff7 100644
--- a/drivers/dma/ti/Makefile
+++ b/drivers/dma/ti/Makefile
@@ -7,5 +7,6 @@ obj-$(CONFIG_TI_K3_UDMA_GLUE_LAYER) += k3-udma-glue.o
obj-$(CONFIG_TI_K3_PSIL) += k3-psil.o \
k3-psil-am654.o \
k3-psil-j721e.o \
- k3-psil-j7200.o
+ k3-psil-j7200.o \
+ k3-psil-am64.o
obj-$(CONFIG_TI_DMA_CROSSBAR) += dma-crossbar.o
diff --git a/drivers/dma/ti/k3-psil-am64.c b/drivers/dma/ti/k3-psil-am64.c
new file mode 100644
index ..e88f57a36ac1
--- /dev/null
+++ b/drivers/dma/ti/k3-psil-am64.c
@@ -0,0 +1,75 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2020 Texas Instruments Incorporated - https://www.ti.com
+ * Author: Peter Ujfalusi
+ */
+
+#include
+
+#include "k3-psil-priv.h"
+
+#define PSIL_ETHERNET(x, ch, flow_base, flow_cnt) \
+ { \
+ .thread_id = x, \
+ .ep_config = { \
+ .ep_type = PSIL_EP_NATIVE, \
+ .pkt_mode = 1, \
+ .needs_epib = 1,\
+ .psd_size = 16, \
+ .mapped_channel_id = ch,\
+ .flow_start = flow_base,\
+ .flow_num = flow_cnt, \
+ .default_flow_id = flow_base, \
+ }, \
+ }
+
+#define PSIL_SAUL(x, ch, flow_base, flow_cnt, default_flow, tx)\
+ { \
+ .thread_id = x, \
+ .ep_config = { \
+ .ep_type = PSIL_EP_NATIVE, \
+ .pkt_mode = 1, \
+ .needs_epib = 1,\
+ .psd_size = 64, \
+ .mapped_channel_id = ch,\
+ .flow_start = flow_base,\
+ .flow_num = flow_cnt, \
+ .default_flow_id = default_flow,\
+ .notdpkt = tx, \
+ }, \
+ }
+
+/* PSI-L source thread IDs, used for RX (DMA_DEV_TO_MEM) */
+static struct psil_ep am64_src_ep_map[] = {
+ /* SA2UL */
+ PSIL_SAUL(0x4000, 17, 32, 8, 32, 0),
+ PSIL_SAUL(0x4001, 18, 32, 8, 33, 0),
+ PSIL_SAUL(0x4002, 19, 40, 8, 40, 0),
+ PSIL_SAUL(0x4003, 20, 40, 8, 41, 0),
+ /* CPSW3G */
+ PSIL_ETHERNET(0x4500, 16, 16, 16),
+};
+
+/* PSI-L destination thread IDs, used for TX (DMA_MEM_TO_DEV) */
+static struct psil_ep am64_dst_ep_map[] = {
+ /* SA2UL */
+ PSIL_SAUL(0xc000, 24, 80, 8, 80, 1),
+ PSIL_SAUL(0xc001, 25, 88, 8, 88, 1),
+ /* CPSW3G */
+ PSIL_ETHERNET(0xc500, 16, 16, 8),
+ PSIL_ETHERNET(0xc501, 17, 24, 8),
+ PSIL_ETHERNET(0xc502, 18, 32, 8),
+ PSIL_ETHERNET(0xc503, 19, 40, 8),
+ PSIL_ETHERNET(0xc504, 20, 48, 8),
+ PSIL_ETHERNET(0xc505, 21, 56, 8),
+ PSIL_ETHERNET(0xc506, 22, 64, 8),
+ PSIL_ETHERNET(0xc507, 23, 72, 8),
+};
+
+struct psil_ep_map am64_ep_map = {
+ .name = "am64",
+ .src = am64_src_ep_map,
+ .src_count = ARRAY_SIZE(am64_src_ep_map),
+ .dst = am64_dst_ep_map,
+ .dst_count = ARRAY_SIZE(am64_dst_ep_map),
+};
diff --git a/drivers/dma/ti/k3-psil-priv.h b/drivers/dma/ti/k3-psil-priv.h
index b4b0fb359eff..b74e192e3c2d 100644
--- a/drivers/dma/ti/k3-psil-priv.h
+++ b/drivers/dma/ti/k3-psil-priv.h
@@ -40,5 +40,6 @@ struct psil_endpoint_config *psil_get_ep_config(u32
thread_id);
extern struct psil_ep_map am654_ep_map;
extern struct psil_ep_map j721e_ep_map;
extern struct psil_ep_map j7200_ep_map;
+extern struct psil_ep_map am64_ep_map;
#endif /* K3_PSIL_PRIV_H_ */
diff --git a/drivers/dma/ti/k3-psil.c b/drivers/dma/ti/k3-psil.c
index 837853aab95a..13ce7367d870 100644
--- a/drivers/dma/ti/k3-psil.c
+++ b/drivers/dma/ti/k3-psil.c
@@ -20,6 +20,7 @@ static const struct
[PATCH v2 19/19] dmaengine: ti: k3-udma-glue: Add support for K3 PKTDMA
From: Vignesh Raghavendra
This commit adds support for PKTDMA in k3-udma glue driver. Use new
psil_endpoint_config struct to get static data for a given channel or a
flow during setup. Make sure that the RX flows being mapped to a RX
channel is within the range of flows that is been allocated to that RX
channel.
Signed-off-by: Vignesh Raghavendra
Signed-off-by: Peter Ujfalusi
---
drivers/dma/ti/k3-udma-glue.c| 272 ++-
drivers/dma/ti/k3-udma-private.c | 24 +++
drivers/dma/ti/k3-udma.h | 4 +
include/linux/dma/k3-udma-glue.h | 8 +
4 files changed, 270 insertions(+), 38 deletions(-)
diff --git a/drivers/dma/ti/k3-udma-glue.c b/drivers/dma/ti/k3-udma-glue.c
index ddf0730aa2bc..2d0b26a7bf78 100644
--- a/drivers/dma/ti/k3-udma-glue.c
+++ b/drivers/dma/ti/k3-udma-glue.c
@@ -22,6 +22,7 @@
struct k3_udma_glue_common {
struct device *dev;
+ struct device chan_dev;
struct udma_dev *udmax;
const struct udma_tisci_rm *tisci_rm;
struct k3_ringacc *ringacc;
@@ -32,7 +33,8 @@ struct k3_udma_glue_common {
bool epib;
u32 psdata_size;
u32 swdata_size;
- u32 atype;
+ u32 atype_asel;
+ struct psil_endpoint_config *ep_config;
};
struct k3_udma_glue_tx_channel {
@@ -53,6 +55,8 @@ struct k3_udma_glue_tx_channel {
bool tx_filt_einfo;
bool tx_filt_pswords;
bool tx_supr_tdpkt;
+
+ int udma_tflow_id;
};
struct k3_udma_glue_rx_flow {
@@ -104,7 +108,6 @@ static int of_k3_udma_glue_parse_chn(struct device_node
*chn_np,
const char *name, struct k3_udma_glue_common *common,
bool tx_chn)
{
- struct psil_endpoint_config *ep_config;
struct of_phandle_args dma_spec;
u32 thread_id;
int ret = 0;
@@ -121,15 +124,26 @@ static int of_k3_udma_glue_parse_chn(struct device_node
*chn_np,
_spec))
return -ENOENT;
+ ret = of_k3_udma_glue_parse(dma_spec.np, common);
+ if (ret)
+ goto out_put_spec;
+
thread_id = dma_spec.args[0];
if (dma_spec.args_count == 2) {
- if (dma_spec.args[1] > 2) {
+ if (dma_spec.args[1] > 2 && !xudma_is_pktdma(common->udmax)) {
dev_err(common->dev, "Invalid channel atype: %u\n",
dma_spec.args[1]);
ret = -EINVAL;
goto out_put_spec;
}
- common->atype = dma_spec.args[1];
+ if (dma_spec.args[1] > 15 && xudma_is_pktdma(common->udmax)) {
+ dev_err(common->dev, "Invalid channel asel: %u\n",
+ dma_spec.args[1]);
+ ret = -EINVAL;
+ goto out_put_spec;
+ }
+
+ common->atype_asel = dma_spec.args[1];
}
if (tx_chn && !(thread_id & K3_PSIL_DST_THREAD_ID_OFFSET)) {
@@ -143,25 +157,23 @@ static int of_k3_udma_glue_parse_chn(struct device_node
*chn_np,
}
/* get psil endpoint config */
- ep_config = psil_get_ep_config(thread_id);
- if (IS_ERR(ep_config)) {
+ common->ep_config = psil_get_ep_config(thread_id);
+ if (IS_ERR(common->ep_config)) {
dev_err(common->dev,
"No configuration for psi-l thread 0x%04x\n",
thread_id);
- ret = PTR_ERR(ep_config);
+ ret = PTR_ERR(common->ep_config);
goto out_put_spec;
}
- common->epib = ep_config->needs_epib;
- common->psdata_size = ep_config->psd_size;
+ common->epib = common->ep_config->needs_epib;
+ common->psdata_size = common->ep_config->psd_size;
if (tx_chn)
common->dst_thread = thread_id;
else
common->src_thread = thread_id;
- ret = of_k3_udma_glue_parse(dma_spec.np, common);
-
out_put_spec:
of_node_put(dma_spec.np);
return ret;
@@ -227,7 +239,7 @@ static int k3_udma_glue_cfg_tx_chn(struct
k3_udma_glue_tx_channel *tx_chn)
req.tx_supr_tdpkt = 1;
req.tx_fetch_size = tx_chn->common.hdesc_size >> 2;
req.txcq_qnum = k3_ringacc_get_ring_id(tx_chn->ringtxcq);
- req.tx_atype = tx_chn->common.atype;
+ req.tx_atype = tx_chn->common.atype_asel;
return tisci_rm->tisci_udmap_ops->tx_ch_cfg(tisci_rm->tisci, );
}
@@ -259,8 +271,14 @@ struct k3_udma_glue_tx_channel
*k3_udma_glue_request_tx_chn(struct device *dev,
tx_chn->common.psdata_size,
tx_chn->common.swdata_size);
+ if (xudma_is_pktdm
[PATCH v2 14/19] dmaengine: ti: Add support for k3 event routers
In k3 architecture a DMA channel (in TR momde) can be triggered by global
events, origination from different modules.
The events for triggers can be sent from any module which is connected to
PSI-L fabric, but the event number to be sent is DMA channel specific, it
is only known after the channel itself is requested.
The router operation needs to be split up:
- route_allocate: configure the dma_spec for the DMA and store the
configuration which is needed for the router's input
- set_event: callback used by the DMA driver to set the event number for
the channel and enable the routing
Signed-off-by: Peter Ujfalusi
---
include/linux/dma/k3-event-router.h | 16
1 file changed, 16 insertions(+)
create mode 100644 include/linux/dma/k3-event-router.h
diff --git a/include/linux/dma/k3-event-router.h
b/include/linux/dma/k3-event-router.h
new file mode 100644
index ..e3f88b2f87be
--- /dev/null
+++ b/include/linux/dma/k3-event-router.h
@@ -0,0 +1,16 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Copyright (C) 2020 Texas Instruments Incorporated - https://www.ti.com
+ */
+
+#ifndef K3_EVENT_ROUTER_
+#define K3_EVENT_ROUTER_
+
+#include
+
+struct k3_event_route_data {
+ void *priv;
+ int (*set_event)(void *priv, u32 event);
+};
+
+#endif /* K3_EVENT_ROUTER_ */
--
Peter
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
[PATCH v2 15/19] soc: ti: k3-ringacc: add AM64 DMA rings support.
From: Grygorii Strashko
The DMAs in AM64 have built in rings compared to AM654/J721e/J7200 where a
separate and generic ringacc is used.
The ring SW interface is similar to ringacc with some major architectural
differences, like
They are part of the DMA (BCDMA or PKTDMA).
They are dual mode rings are modeled as pair of Rings objects which has
common configuration and memory buffer, but separate real-time control
register sets for each direction mem2dev (forward) and dev2mem (reverse).
The ringacc driver must be initialized for DMA rings use with
k3_ringacc_dmarings_init() as it is not an independent device as ringacc
is.
AM64 rings must be requested only using k3_ringacc_request_rings_pair(),
and forward ring must always be initialized/configured. After this any
other Ringacc APIs can be used without any callers changes.
Signed-off-by: Grygorii Strashko
Signed-off-by: Peter Ujfalusi
---
drivers/soc/ti/k3-ringacc.c | 325 +-
include/linux/soc/ti/k3-ringacc.h | 17 ++
2 files changed, 335 insertions(+), 7 deletions(-)
diff --git a/drivers/soc/ti/k3-ringacc.c b/drivers/soc/ti/k3-ringacc.c
index 7fdb688452f7..44879f45575d 100644
--- a/drivers/soc/ti/k3-ringacc.c
+++ b/drivers/soc/ti/k3-ringacc.c
@@ -11,6 +11,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -21,6 +22,7 @@ static LIST_HEAD(k3_ringacc_list);
static DEFINE_MUTEX(k3_ringacc_list_lock);
#define K3_RINGACC_CFG_RING_SIZE_ELCNT_MASKGENMASK(19, 0)
+#define K3_DMARING_CFG_RING_SIZE_ELCNT_MASKGENMASK(15, 0)
/**
* struct k3_ring_rt_regs - The RA realtime Control/Status Registers region
@@ -43,7 +45,13 @@ struct k3_ring_rt_regs {
u32 hwindx;
};
-#define K3_RINGACC_RT_REGS_STEP0x1000
+#define K3_RINGACC_RT_REGS_STEP0x1000
+#define K3_DMARING_RT_REGS_STEP0x2000
+#define K3_DMARING_RT_REGS_REVERSE_OFS 0x1000
+#define K3_RINGACC_RT_OCC_MASK GENMASK(20, 0)
+#define K3_DMARING_RT_OCC_TDOWN_COMPLETE BIT(31)
+#define K3_DMARING_RT_DB_ENTRY_MASKGENMASK(7, 0)
+#define K3_DMARING_RT_DB_TDOWN_ACK BIT(31)
/**
* struct k3_ring_fifo_regs - The Ring Accelerator Queues Registers region
@@ -122,6 +130,7 @@ struct k3_ring_state {
u32 occ;
u32 windex;
u32 rindex;
+ u32 tdown_complete:1;
};
/**
@@ -142,6 +151,7 @@ struct k3_ring_state {
* @use_count: Use count for shared rings
* @proxy_id: RA Ring Proxy Id (only if @K3_RINGACC_RING_USE_PROXY)
* @dma_dev: device to be used for DMA API (allocation, mapping)
+ * @asel: Address Space Select value for physical addresses
*/
struct k3_ring {
struct k3_ring_rt_regs __iomem *rt;
@@ -156,12 +166,15 @@ struct k3_ring {
u32 flags;
#define K3_RING_FLAG_BUSY BIT(1)
#define K3_RING_FLAG_SHAREDBIT(2)
+#define K3_RING_FLAG_REVERSE BIT(3)
struct k3_ring_state state;
u32 ring_id;
struct k3_ringacc *parent;
u32 use_count;
int proxy_id;
struct device *dma_dev;
+ u32 asel;
+#define K3_ADDRESS_ASEL_SHIFT 48
};
struct k3_ringacc_ops {
@@ -187,6 +200,7 @@ struct k3_ringacc_ops {
* @tisci_ring_ops: ti-sci rings ops
* @tisci_dev_id: ti-sci device id
* @ops: SoC specific ringacc operation
+ * @dma_rings: indicate DMA ring (dual ring within BCDMA/PKTDMA)
*/
struct k3_ringacc {
struct device *dev;
@@ -209,6 +223,7 @@ struct k3_ringacc {
u32 tisci_dev_id;
const struct k3_ringacc_ops *ops;
+ bool dma_rings;
};
/**
@@ -220,6 +235,21 @@ struct k3_ringacc_soc_data {
unsigned dma_ring_reset_quirk:1;
};
+static int k3_ringacc_ring_read_occ(struct k3_ring *ring)
+{
+ return readl(>rt->occ) & K3_RINGACC_RT_OCC_MASK;
+}
+
+static void k3_ringacc_ring_update_occ(struct k3_ring *ring)
+{
+ u32 val;
+
+ val = readl(>rt->occ);
+
+ ring->state.occ = val & K3_RINGACC_RT_OCC_MASK;
+ ring->state.tdown_complete = !!(val & K3_DMARING_RT_OCC_TDOWN_COMPLETE);
+}
+
static long k3_ringacc_ring_get_fifo_pos(struct k3_ring *ring)
{
return K3_RINGACC_FIFO_WINDOW_SIZE_BYTES -
@@ -233,12 +263,24 @@ static void *k3_ringacc_get_elm_addr(struct k3_ring
*ring, u32 idx)
static int k3_ringacc_ring_push_mem(struct k3_ring *ring, void *elem);
static int k3_ringacc_ring_pop_mem(struct k3_ring *ring, void *elem);
+static int k3_dmaring_fwd_pop(struct k3_ring *ring, void *elem);
+static int k3_dmaring_reverse_pop(struct k3_ring *ring, void *elem);
static struct k3_ring_ops k3_ring_mode_ring_ops = {
.push_tail = k3_ringacc_ring_push_mem,
.pop_head = k3_ringacc_ring_pop_mem,
};
+static struct k3_ring_ops k3_dmaring_fwd_ops = {
+ .push_tail = k3_ringacc_ring_push_
[PATCH v2 11/19] dt-bindings: dma: ti: Add document for K3 PKTDMA
New binding document for
Texas Instruments K3 Packet DMA (PKTDMA).
PKTDMA is introduced as part of AM64.
Signed-off-by: Peter Ujfalusi
---
.../devicetree/bindings/dma/ti/k3-pktdma.yaml | 183 ++
1 file changed, 183 insertions(+)
create mode 100644 Documentation/devicetree/bindings/dma/ti/k3-pktdma.yaml
diff --git a/Documentation/devicetree/bindings/dma/ti/k3-pktdma.yaml
b/Documentation/devicetree/bindings/dma/ti/k3-pktdma.yaml
new file mode 100644
index ..bf49b0135fbe
--- /dev/null
+++ b/Documentation/devicetree/bindings/dma/ti/k3-pktdma.yaml
@@ -0,0 +1,183 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/dma/ti/k3-pktdma.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Texas Instruments K3 DMSS PKTDMA Device Tree Bindings
+
+maintainers:
+ - Peter Ujfalusi
+
+description: |
+ The Packet DMA (PKTDMA) is intended to perform similar functions as the
packet
+ mode channels of K3 UDMA-P.
+ PKTDMA only includes Split channels to service PSI-L based peripherals.
+
+ The peripherals can be PSI-L native or legacy, non PSI-L native peripherals
+ with PDMAs. PDMA is tasked to act as a bridge between the PSI-L fabric and
the
+ legacy peripheral.
+
+ PDMAs can be configured via PKTDMA split channel's peer registers to match
+ with the configuration of the legacy peripheral.
+
+allOf:
+ - $ref: /schemas/dma/dma-controller.yaml#
+
+properties:
+ "#dma-cells":
+const: 2
+description: |
+ The first cell is the PSI-L thread ID of the remote (to PKTDMA) end.
+ Valid ranges for thread ID depends on the data movement direction:
+ for source thread IDs (rx): 0 - 0x7fff
+ for destination thread IDs (tx): 0x8000 - 0x
+
+ Please refer to the device documentation for the PSI-L thread map and
also
+ the PSI-L peripheral chapter for the correct thread ID.
+
+ The second cell is the ASEL value for the channel
+
+ compatible:
+enum:
+ - ti,am64-dmss-pktdma
+
+ "#address-cells":
+const: 2
+
+ "#size-cells":
+const: 2
+
+ reg:
+maxItems: 4
+
+ reg-names:
+items:
+ - const: gcfg
+ - const: rchanrt
+ - const: tchanrt
+ - const: ringrt
+
+ msi-parent: true
+
+ ti,sci-rm-range-tchan:
+$ref: /schemas/types.yaml#/definitions/uint32-array
+description: |
+ Array of PKTDMA split tx channel resource subtypes for resource
allocation
+ for this host
+minItems: 1
+# Should be enough
+maxItems: 255
+items:
+ maximum: 0x3f
+
+ ti,sci-rm-range-tflow:
+$ref: /schemas/types.yaml#/definitions/uint32-array
+description: |
+ Array of PKTDMA split tx flow resource subtypes for resource allocation
+ for this host
+minItems: 1
+# Should be enough
+maxItems: 255
+items:
+ maximum: 0x3f
+
+ ti,sci-rm-range-rchan:
+$ref: /schemas/types.yaml#/definitions/uint32-array
+description: |
+ Array of PKTDMA split rx channel resource subtypes for resource
allocation
+ for this host
+minItems: 1
+# Should be enough
+maxItems: 255
+items:
+ maximum: 0x3f
+
+ ti,sci-rm-range-rflow:
+$ref: /schemas/types.yaml#/definitions/uint32-array
+description: |
+ Array of PKTDMA split rx flow resource subtypes for resource allocation
+ for this host
+minItems: 1
+# Should be enough
+maxItems: 255
+items:
+ maximum: 0x3f
+
+required:
+ - compatible
+ - "#address-cells"
+ - "#size-cells"
+ - "#dma-cells"
+ - reg
+ - reg-names
+ - msi-parent
+ - ti,sci
+ - ti,sci-dev-id
+ - ti,sci-rm-range-tchan
+ - ti,sci-rm-range-tflow
+ - ti,sci-rm-range-rchan
+ - ti,sci-rm-range-rflow
+
+unevaluatedProperties: false
+
+examples:
+ - |+
+cbass_main {
+#address-cells = <2>;
+#size-cells = <2>;
+
+main_dmss {
+compatible = "simple-mfd";
+#address-cells = <2>;
+#size-cells = <2>;
+dma-ranges;
+ranges;
+
+ti,sci-dev-id = <25>;
+
+main_pktdma: dma-controller@485c {
+compatible = "ti,am64-dmss-pktdma";
+#address-cells = <2>;
+#size-cells = <2>;
+
+reg = <0x0 0x485c 0x0 0x100>,
+ <0x0 0x4a80 0x0 0x2>,
+ <0x0 0x4aa0 0x0 0x4>,
+ <0x0 0x4b80 0x0 0x40>;
+reg-names = "gcfg", "rchanrt", "tchanrt", "ringrt";
+msi-parent = <_main_dmss>;
+#dma-cells = <2>;
+
+ti,sci = <>;
+ti,sci-dev-id = <30>;
+
+ti,sci-rm-range-tchan = <0x23>, /* UNMAPPED
[PATCH v2 12/19] dmaengine: ti: k3-psil: Extend psil_endpoint_config for K3 PKTDMA
Additional fields needed for K3 PKTDMA to be able to handle the mapped
channels (channels are locked to handle specific threads) and flow ranges
for these mapped threads.
PKTDMA also introduces tflow for tx channels which can not be found in
K3 UDMA architecture.
Signed-off-by: Peter Ujfalusi
---
include/linux/dma/k3-psil.h | 16
1 file changed, 16 insertions(+)
diff --git a/include/linux/dma/k3-psil.h b/include/linux/dma/k3-psil.h
index 1962f75fa2d3..36e22c5a0f29 100644
--- a/include/linux/dma/k3-psil.h
+++ b/include/linux/dma/k3-psil.h
@@ -50,6 +50,15 @@ enum psil_endpoint_type {
* @channel_tpl: Desired throughput level for the channel
* @pdma_acc32:ACC32 must be enabled on the PDMA side
* @pdma_burst:BURST must be enabled on the PDMA side
+ * @mapped_channel_id: PKTDMA thread to channel mapping for mapped channels.
+ * The thread must be serviced by the specified channel if
+ * mapped_channel_id is >= 0 in case of PKTDMA
+ * @flow_start:PKDMA flow range start of mapped channel.
Unmapped
+ * channels use flow_id == chan_id
+ * @flow_num: PKDMA flow count of mapped channel. Unmapped channels
+ * use flow_id == chan_id
+ * @default_flow_id: PKDMA default (r)flow index of mapped channel.
+ * Must be within the flow range of the mapped channel.
*/
struct psil_endpoint_config {
enum psil_endpoint_type ep_type;
@@ -63,6 +72,13 @@ struct psil_endpoint_config {
/* PDMA properties, valid for PSIL_EP_PDMA_* */
unsigned pdma_acc32:1;
unsigned pdma_burst:1;
+
+ /* PKDMA mapped channel */
+ int mapped_channel_id;
+ /* PKTDMA tflow and rflow ranges for mapped channel */
+ u16 flow_start;
+ u16 flow_num;
+ u16 default_flow_id;
};
int psil_set_new_ep_config(struct device *dev, const char *name,
--
Peter
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
[PATCH v2 07/19] dmaengine: Add support for per channel coherency handling
If the DMA device supports per channel coherency configuration (a channel
can be configured to have coherent or not coherent view) then a single
device (the DMA controller's device) can not be used for dma_api for all
channels as channels can have different coherency.
Introduce custom_dma_mapping flag for the dma_chan and a new helper to get
the device pointer to be used for dma_api for the given channel.
Client drivers should be updated to be able to support per channel
coherency by:
- dma_map_single(chan->device->dev, ptr, size, DMA_TO_DEVICE);
+ struct device *dma_dev = dmaengine_get_dma_device(chan);
+
+ dma_map_single(dma_dev, ptr, size, DMA_TO_DEVICE);
Signed-off-by: Peter Ujfalusi
---
include/linux/dmaengine.h | 12
1 file changed, 12 insertions(+)
diff --git a/include/linux/dmaengine.h b/include/linux/dmaengine.h
index d6197fe875af..182a1a2e7793 100644
--- a/include/linux/dmaengine.h
+++ b/include/linux/dmaengine.h
@@ -357,11 +357,14 @@ struct dma_chan {
* @chan: driver channel device
* @device: sysfs device
* @dev_id: parent dma_device dev_id
+ * @chan_dma_dev: The channel is using custom/different dma-mapping
+ * compared to the parent dma_device
*/
struct dma_chan_dev {
struct dma_chan *chan;
struct device device;
int dev_id;
+ bool chan_dma_dev;
};
/**
@@ -1613,4 +1616,13 @@ dmaengine_get_direction_text(enum dma_transfer_direction
dir)
return "invalid";
}
}
+
+static inline struct device *dmaengine_get_dma_device(struct dma_chan *chan)
+{
+ if (chan->dev->chan_dma_dev)
+ return >dev->device;
+
+ return chan->device->dev;
+}
+
#endif /* DMAENGINE_H */
--
Peter
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
[PATCH v2 10/19] dt-bindings: dma: ti: Add document for K3 BCDMA
New binding document for
Texas Instruments K3 Block Copy DMA (BCDMA).
BCDMA is introduced as part of AM64.
Signed-off-by: Peter Ujfalusi
---
.../devicetree/bindings/dma/ti/k3-bcdma.yaml | 175 ++
1 file changed, 175 insertions(+)
create mode 100644 Documentation/devicetree/bindings/dma/ti/k3-bcdma.yaml
diff --git a/Documentation/devicetree/bindings/dma/ti/k3-bcdma.yaml
b/Documentation/devicetree/bindings/dma/ti/k3-bcdma.yaml
new file mode 100644
index ..c6d76641ebec
--- /dev/null
+++ b/Documentation/devicetree/bindings/dma/ti/k3-bcdma.yaml
@@ -0,0 +1,175 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/dma/ti/k3-bcdma.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Texas Instruments K3 DMSS BCDMA Device Tree Bindings
+
+maintainers:
+ - Peter Ujfalusi
+
+description: |
+ The Block Copy DMA (BCDMA) is intended to perform similar functions as the TR
+ mode channels of K3 UDMA-P.
+ BCDMA includes block copy channels and Split channels.
+
+ Block copy channels mainly used for memory to memory transfers, but with
+ optional triggers a block copy channel can service peripherals by accessing
+ directly to memory mapped registers or area.
+
+ Split channels can be used to service PSI-L based peripherals.
+ The peripherals can be PSI-L native or legacy, non PSI-L native peripherals
+ with PDMAs. PDMA is tasked to act as a bridge between the PSI-L fabric and
the
+ legacy peripheral.
+
+ PDMAs can be configured via BCDMA split channel's peer registers to match
with
+ the configuration of the legacy peripheral.
+
+allOf:
+ - $ref: /schemas/dma/dma-controller.yaml#
+
+properties:
+ "#dma-cells":
+const: 3
+description: |
+ cell 1: type of the BCDMA channel to be used to service the peripheral:
+0 - split channel
+1 - block copy channel using global trigger 1
+2 - block copy channel using global trigger 2
+3 - block copy channel using local trigger
+
+ cell 2: parameter for the channel:
+if cell 1 is 0 (split channel):
+ PSI-L thread ID of the remote (to BCDMA) end.
+ Valid ranges for thread ID depends on the data movement direction:
+ for source thread IDs (rx): 0 - 0x7fff
+ for destination thread IDs (tx): 0x8000 - 0x
+
+ Please refer to the device documentation for the PSI-L thread map and
+ also the PSI-L peripheral chapter for the correct thread ID.
+if cell 1 is 1 or 2 (block copy channel using global trigger):
+ Unused, ignored
+
+ The trigger must be configured for the channel externally to BCDMA,
+ channels using global triggers should not be requested directly, but
+ via DMA event router.
+if cell 1 is 3 (block copy channel using local trigger):
+ bchan number of the locally triggered channel
+
+ cell 3: ASEL value for the channel
+
+ compatible:
+enum:
+ - ti,am64-dmss-bcdma
+
+ "#address-cells":
+const: 2
+
+ "#size-cells":
+const: 2
+
+ reg:
+maxItems: 5
+
+ reg-names:
+items:
+ - const: gcfg
+ - const: bchanrt
+ - const: rchanrt
+ - const: tchanrt
+ - const: ringrt
+
+ msi-parent: true
+
+ ti,asel:
+$ref: /schemas/types.yaml#/definitions/uint32
+description: ASEL value for non slave channels
+
+ ti,sci-rm-range-bchan:
+$ref: /schemas/types.yaml#/definitions/uint32-array
+description: |
+ Array of BCDMA block-copy channel resource subtypes for resource
+ allocation for this host
+minItems: 1
+# Should be enough
+maxItems: 255
+items:
+ maximum: 0x3f
+
+ ti,sci-rm-range-tchan:
+$ref: /schemas/types.yaml#/definitions/uint32-array
+description: |
+ Array of BCDMA split tx channel resource subtypes for resource allocation
+ for this host
+minItems: 1
+# Should be enough
+maxItems: 255
+items:
+ maximum: 0x3f
+
+ ti,sci-rm-range-rchan:
+$ref: /schemas/types.yaml#/definitions/uint32-array
+description: |
+ Array of BCDMA split rx channel resource subtypes for resource allocation
+ for this host
+minItems: 1
+# Should be enough
+maxItems: 255
+items:
+ maximum: 0x3f
+
+required:
+ - compatible
+ - "#address-cells"
+ - "#size-cells"
+ - "#dma-cells"
+ - reg
+ - reg-names
+ - msi-parent
+ - ti,sci
+ - ti,sci-dev-id
+ - ti,sci-rm-range-bchan
+ - ti,sci-rm-range-tchan
+ - ti,sci-rm-range-rchan
+
+unevaluatedProperties: false
+
+examples:
+ - |+
+cbass_main {
+#address-cells = <2>;
+#size-cells = <2>;
+
+main_dmss {
+compatible = "simple-mfd";
+#address-cells = <2>;
+#size-cells = <2>;
+dma-ranges;
+r
[PATCH v2 08/19] dmaengine: doc: client: Update for dmaengine_get_dma_device() usage
Client drivers should use the dmaengine_get_dma_device(chan) to get the device pointer which should be used for DMA API for allocations and mapping. Signed-off-by: Peter Ujfalusi --- Documentation/driver-api/dmaengine/client.rst | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/Documentation/driver-api/dmaengine/client.rst b/Documentation/driver-api/dmaengine/client.rst index 09a3f66dcd26..bfd057b21a00 100644 --- a/Documentation/driver-api/dmaengine/client.rst +++ b/Documentation/driver-api/dmaengine/client.rst @@ -120,7 +120,9 @@ The details of these operations are: .. code-block:: c - nr_sg = dma_map_sg(chan->device->dev, sgl, sg_len); + struct device *dma_dev = dmaengine_get_dma_device(chan); + + nr_sg = dma_map_sg(dma_dev, sgl, sg_len); if (nr_sg == 0) /* error */ -- Peter Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
[PATCH v2 09/19] dmaengine: dmatest: Use dmaengine_get_dma_device
By using the dmaengine_get_dma_device() to get the device for
dma_api use, the dmatest can support per channel coherency if it is
supported by the DMA controller.
Signed-off-by: Peter Ujfalusi
---
drivers/dma/dmatest.c | 13 -
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/drivers/dma/dmatest.c b/drivers/dma/dmatest.c
index a3a172173e34..f696246f57fd 100644
--- a/drivers/dma/dmatest.c
+++ b/drivers/dma/dmatest.c
@@ -573,6 +573,7 @@ static int dmatest_func(void *data)
struct dmatest_params *params;
struct dma_chan *chan;
struct dma_device *dev;
+ struct device *dma_dev;
unsigned interror_count;
unsigned intfailed_tests = 0;
unsigned inttotal_tests = 0;
@@ -606,6 +607,8 @@ static int dmatest_func(void *data)
params = >params;
chan = thread->chan;
dev = chan->device;
+ dma_dev = dmaengine_get_dma_device(chan);
+
src = >src;
dst = >dst;
if (thread->type == DMA_MEMCPY) {
@@ -730,7 +733,7 @@ static int dmatest_func(void *data)
filltime = ktime_add(filltime, diff);
}
- um = dmaengine_get_unmap_data(dev->dev, src->cnt + dst->cnt,
+ um = dmaengine_get_unmap_data(dma_dev, src->cnt + dst->cnt,
GFP_KERNEL);
if (!um) {
failed_tests++;
@@ -745,10 +748,10 @@ static int dmatest_func(void *data)
struct page *pg = virt_to_page(buf);
unsigned long pg_off = offset_in_page(buf);
- um->addr[i] = dma_map_page(dev->dev, pg, pg_off,
+ um->addr[i] = dma_map_page(dma_dev, pg, pg_off,
um->len, DMA_TO_DEVICE);
srcs[i] = um->addr[i] + src->off;
- ret = dma_mapping_error(dev->dev, um->addr[i]);
+ ret = dma_mapping_error(dma_dev, um->addr[i]);
if (ret) {
result("src mapping error", total_tests,
src->off, dst->off, len, ret);
@@ -763,9 +766,9 @@ static int dmatest_func(void *data)
struct page *pg = virt_to_page(buf);
unsigned long pg_off = offset_in_page(buf);
- dsts[i] = dma_map_page(dev->dev, pg, pg_off, um->len,
+ dsts[i] = dma_map_page(dma_dev, pg, pg_off, um->len,
DMA_BIDIRECTIONAL);
- ret = dma_mapping_error(dev->dev, dsts[i]);
+ ret = dma_mapping_error(dma_dev, dsts[i]);
if (ret) {
result("dst mapping error", total_tests,
src->off, dst->off, len, ret);
--
Peter
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
[PATCH v2 05/19] dmaengine: ti: k3-udma-glue: Configure the dma_dev for rings
Rings in RING mode should be using the DMA device for DMA API as in this
mode the ringacc will not access the ring memory in any ways, but the DMA
is.
Fix up the ring configuration and set the dma_dev unconditionally and let
the ringacc driver to select the correct device to use for DMA API.
Signed-off-by: Peter Ujfalusi
---
drivers/dma/ti/k3-udma-glue.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/dma/ti/k3-udma-glue.c b/drivers/dma/ti/k3-udma-glue.c
index 29d1524d1916..ddf0730aa2bc 100644
--- a/drivers/dma/ti/k3-udma-glue.c
+++ b/drivers/dma/ti/k3-udma-glue.c
@@ -280,6 +280,10 @@ struct k3_udma_glue_tx_channel
*k3_udma_glue_request_tx_chn(struct device *dev,
goto err;
}
+ /* Set the dma_dev for the rings to be configured */
+ cfg->tx_cfg.dma_dev = k3_udma_glue_tx_get_dma_device(tx_chn);
+ cfg->txcq_cfg.dma_dev = cfg->tx_cfg.dma_dev;
+
ret = k3_ringacc_ring_cfg(tx_chn->ringtx, >tx_cfg);
if (ret) {
dev_err(dev, "Failed to cfg ringtx %d\n", ret);
@@ -595,6 +599,10 @@ static int k3_udma_glue_cfg_rx_flow(struct
k3_udma_glue_rx_channel *rx_chn,
goto err_rflow_put;
}
+ /* Set the dma_dev for the rings to be configured */
+ flow_cfg->rx_cfg.dma_dev = k3_udma_glue_rx_get_dma_device(rx_chn);
+ flow_cfg->rxfdq_cfg.dma_dev = flow_cfg->rx_cfg.dma_dev;
+
ret = k3_ringacc_ring_cfg(flow->ringrx, _cfg->rx_cfg);
if (ret) {
dev_err(dev, "Failed to cfg ringrx %d\n", ret);
--
Peter
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
[PATCH v2 06/19] dmaengine: of-dma: Add support for optional router configuration callback
Additional configuration for the DMA event router might be needed for a
channel which can not be done during device_alloc_chan_resources callback
since the router information is not yet present for the drivers.
If there is a need for additional configuration for the channel if DMA
router is in use, then the driver can implement the device_router_config
callback.
Signed-off-by: Peter Ujfalusi
---
drivers/dma/of-dma.c | 10 ++
include/linux/dmaengine.h | 2 ++
2 files changed, 12 insertions(+)
diff --git a/drivers/dma/of-dma.c b/drivers/dma/of-dma.c
index 8a4f608904b9..ec00b20ae8e4 100644
--- a/drivers/dma/of-dma.c
+++ b/drivers/dma/of-dma.c
@@ -75,8 +75,18 @@ static struct dma_chan *of_dma_router_xlate(struct
of_phandle_args *dma_spec,
ofdma->dma_router->route_free(ofdma->dma_router->dev,
route_data);
} else {
+ int ret = 0;
+
chan->router = ofdma->dma_router;
chan->route_data = route_data;
+
+ if (chan->device->device_router_config)
+ ret = chan->device->device_router_config(chan);
+
+ if (ret) {
+ dma_release_channel(chan);
+ chan = ERR_PTR(ret);
+ }
}
/*
diff --git a/include/linux/dmaengine.h b/include/linux/dmaengine.h
index dd357a747780..d6197fe875af 100644
--- a/include/linux/dmaengine.h
+++ b/include/linux/dmaengine.h
@@ -800,6 +800,7 @@ struct dma_filter {
* by tx_status
* @device_alloc_chan_resources: allocate resources and return the
* number of allocated descriptors
+ * @device_router_config: optional callback for DMA router configuration
* @device_free_chan_resources: release DMA channel's resources
* @device_prep_dma_memcpy: prepares a memcpy operation
* @device_prep_dma_xor: prepares a xor operation
@@ -874,6 +875,7 @@ struct dma_device {
enum dma_residue_granularity residue_granularity;
int (*device_alloc_chan_resources)(struct dma_chan *chan);
+ int (*device_router_config)(struct dma_chan *chan);
void (*device_free_chan_resources)(struct dma_chan *chan);
struct dma_async_tx_descriptor *(*device_prep_dma_memcpy)(
--
Peter
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
[PATCH v2 02/19] dmaengine: ti: k3-udma: Wait for peer teardown completion if supported
Set the TDTYPE if it is supported on the platform (j721e) which will cause
UDMAP to wait for the remote peer to finish the teardown before returning
the teardown completed message.
Signed-off-by: Peter Ujfalusi
Tested-by: Keerthy
Reviewed-by: Grygorii Strashko
---
drivers/dma/ti/k3-udma.c | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/dma/ti/k3-udma.c b/drivers/dma/ti/k3-udma.c
index 0e8426dd18a7..eee43757e774 100644
--- a/drivers/dma/ti/k3-udma.c
+++ b/drivers/dma/ti/k3-udma.c
@@ -86,6 +86,7 @@ struct udma_rchan {
#define UDMA_FLAG_PDMA_ACC32 BIT(0)
#define UDMA_FLAG_PDMA_BURST BIT(1)
+#define UDMA_FLAG_TDTYPE BIT(2)
struct udma_match_data {
u32 psil_base;
@@ -1589,6 +1590,13 @@ static int udma_tisci_tx_channel_config(struct udma_chan
*uc)
req_tx.tx_fetch_size = fetch_size >> 2;
req_tx.txcq_qnum = tc_ring;
req_tx.tx_atype = uc->config.atype;
+ if (uc->config.ep_type == PSIL_EP_PDMA_XY &&
+ ud->match_data->flags & UDMA_FLAG_TDTYPE) {
+ /* wait for peer to complete the teardown for PDMAs */
+ req_tx.valid_params |=
+ TI_SCI_MSG_VALUE_RM_UDMAP_CH_TX_TDTYPE_VALID;
+ req_tx.tx_tdtype = 1;
+ }
ret = tisci_ops->tx_ch_cfg(tisci_rm->tisci, _tx);
if (ret)
@@ -3105,14 +3113,14 @@ static struct udma_match_data am654_mcu_data = {
static struct udma_match_data j721e_main_data = {
.psil_base = 0x1000,
.enable_memcpy_support = true,
- .flags = UDMA_FLAG_PDMA_ACC32 | UDMA_FLAG_PDMA_BURST,
+ .flags = UDMA_FLAG_PDMA_ACC32 | UDMA_FLAG_PDMA_BURST | UDMA_FLAG_TDTYPE,
.statictr_z_mask = GENMASK(23, 0),
};
static struct udma_match_data j721e_mcu_data = {
.psil_base = 0x6000,
.enable_memcpy_support = false, /* MEM_TO_MEM is slow via MCU UDMA */
- .flags = UDMA_FLAG_PDMA_ACC32 | UDMA_FLAG_PDMA_BURST,
+ .flags = UDMA_FLAG_PDMA_ACC32 | UDMA_FLAG_PDMA_BURST | UDMA_FLAG_TDTYPE,
.statictr_z_mask = GENMASK(23, 0),
};
--
Peter
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
[PATCH v2 01/19] dmaengine: ti: k3-udma: Correct normal channel offset when uchan_cnt is not 0
According to different sections of the TRM, the hchan_cnt of CAP3 includes
the number of uchan in UDMA, thus the start offset of the normal channels
are hchan_cnt.
Fixes: daf4ad0499aa4 ("dmaengine: ti: k3-udma: Query throughput level
information from hardware")
Signed-off-by: Peter Ujfalusi
---
drivers/dma/ti/k3-udma.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/dma/ti/k3-udma.c b/drivers/dma/ti/k3-udma.c
index e508280b3d70..0e8426dd18a7 100644
--- a/drivers/dma/ti/k3-udma.c
+++ b/drivers/dma/ti/k3-udma.c
@@ -3199,8 +3199,7 @@ static int udma_setup_resources(struct udma_dev *ud)
} else if (UDMA_CAP3_UCHAN_CNT(cap3)) {
ud->tpl_levels = 3;
ud->tpl_start_idx[1] = UDMA_CAP3_UCHAN_CNT(cap3);
- ud->tpl_start_idx[0] = ud->tpl_start_idx[1] +
- UDMA_CAP3_HCHAN_CNT(cap3);
+ ud->tpl_start_idx[0] = UDMA_CAP3_HCHAN_CNT(cap3);
} else if (UDMA_CAP3_HCHAN_CNT(cap3)) {
ud->tpl_levels = 2;
ud->tpl_start_idx[0] = UDMA_CAP3_HCHAN_CNT(cap3);
--
Peter
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
[PATCH v2 03/19] dmaengine: ti: k3-udma: Add support for second resource range from sysfw
Resource allocation via sysfw can use up to two ranges per resource subtype
to support more complex resource assignment, mainly for DMA channels.
Take the second range also into consideration when setting up the maps for
available resources.
Signed-off-by: Peter Ujfalusi
---
drivers/dma/ti/k3-udma.c | 55 ++--
1 file changed, 31 insertions(+), 24 deletions(-)
diff --git a/drivers/dma/ti/k3-udma.c b/drivers/dma/ti/k3-udma.c
index eee43757e774..b89afa602532 100644
--- a/drivers/dma/ti/k3-udma.c
+++ b/drivers/dma/ti/k3-udma.c
@@ -3174,12 +3174,22 @@ static int udma_get_mmrs(struct platform_device *pdev,
struct udma_dev *ud)
return 0;
}
+static void udma_mark_resource_ranges(struct udma_dev *ud, unsigned long *map,
+ struct ti_sci_resource_desc *rm_desc,
+ char *name)
+{
+ bitmap_clear(map, rm_desc->start, rm_desc->num);
+ bitmap_clear(map, rm_desc->start_sec, rm_desc->num_sec);
+ dev_dbg(ud->dev, "ti_sci resource range for %s: %d:%d | %d:%d\n", name,
+ rm_desc->start, rm_desc->num, rm_desc->start_sec,
+ rm_desc->num_sec);
+}
+
static int udma_setup_resources(struct udma_dev *ud)
{
struct device *dev = ud->dev;
int ch_count, ret, i, j;
u32 cap2, cap3;
- struct ti_sci_resource_desc *rm_desc;
struct ti_sci_resource *rm_res, irq_res;
struct udma_tisci_rm *tisci_rm = >tisci_rm;
static const char * const range_names[] = { "ti,sci-rm-range-tchan",
@@ -3264,13 +3274,9 @@ static int udma_setup_resources(struct udma_dev *ud)
bitmap_zero(ud->tchan_map, ud->tchan_cnt);
} else {
bitmap_fill(ud->tchan_map, ud->tchan_cnt);
- for (i = 0; i < rm_res->sets; i++) {
- rm_desc = _res->desc[i];
- bitmap_clear(ud->tchan_map, rm_desc->start,
-rm_desc->num);
- dev_dbg(dev, "ti-sci-res: tchan: %d:%d\n",
- rm_desc->start, rm_desc->num);
- }
+ for (i = 0; i < rm_res->sets; i++)
+ udma_mark_resource_ranges(ud, ud->tchan_map,
+ _res->desc[i], "tchan");
}
irq_res.sets = rm_res->sets;
@@ -3280,13 +3286,9 @@ static int udma_setup_resources(struct udma_dev *ud)
bitmap_zero(ud->rchan_map, ud->rchan_cnt);
} else {
bitmap_fill(ud->rchan_map, ud->rchan_cnt);
- for (i = 0; i < rm_res->sets; i++) {
- rm_desc = _res->desc[i];
- bitmap_clear(ud->rchan_map, rm_desc->start,
-rm_desc->num);
- dev_dbg(dev, "ti-sci-res: rchan: %d:%d\n",
- rm_desc->start, rm_desc->num);
- }
+ for (i = 0; i < rm_res->sets; i++)
+ udma_mark_resource_ranges(ud, ud->rchan_map,
+ _res->desc[i], "rchan");
}
irq_res.sets += rm_res->sets;
@@ -3295,12 +3297,21 @@ static int udma_setup_resources(struct udma_dev *ud)
for (i = 0; i < rm_res->sets; i++) {
irq_res.desc[i].start = rm_res->desc[i].start;
irq_res.desc[i].num = rm_res->desc[i].num;
+ irq_res.desc[i].start_sec = rm_res->desc[i].start_sec;
+ irq_res.desc[i].num_sec = rm_res->desc[i].num_sec;
}
rm_res = tisci_rm->rm_ranges[RM_RANGE_RCHAN];
for (j = 0; j < rm_res->sets; j++, i++) {
- irq_res.desc[i].start = rm_res->desc[j].start +
+ if (rm_res->desc[j].num) {
+ irq_res.desc[i].start = rm_res->desc[j].start +
ud->soc_data->rchan_oes_offset;
- irq_res.desc[i].num = rm_res->desc[j].num;
+ irq_res.desc[i].num = rm_res->desc[j].num;
+ }
+ if (rm_res->desc[j].num_sec) {
+ irq_res.desc[i].start_sec = rm_res->desc[j].start_sec +
+ ud->soc_data->rchan_oes_offset;
+ irq_res.desc[i].num_sec = rm_res->desc[j].num_sec;
+ }
}
ret = ti_sci_inta_msi_domain_alloc_irqs(ud->dev, _res);
kfree(irq_res.desc);
@@ -3316,13 +3327,9 @@ static int udma_setup_resources(struct udma_dev *ud)
bitmap_clear(ud->rflow_gp_map, ud->rchan_cnt,
ud->rflow_cnt - ud->rchan_cnt);
[PATCH] ARM: dts: keystone-k2g-evm: add HDMI and analog audio data
The board is using McASP2 for both analog (tlv320aic3106) and
HDMI (SiI9022) audio.
Signed-off-by: Peter Ujfalusi
---
arch/arm/boot/dts/keystone-k2g-evm.dts | 112 +
1 file changed, 112 insertions(+)
diff --git a/arch/arm/boot/dts/keystone-k2g-evm.dts
b/arch/arm/boot/dts/keystone-k2g-evm.dts
index 8b3d64c913d8..4d7e3514a3a7 100644
--- a/arch/arm/boot/dts/keystone-k2g-evm.dts
+++ b/arch/arm/boot/dts/keystone-k2g-evm.dts
@@ -46,6 +46,14 @@ vcc1v8_ldo1_reg: fixedregulator-vcc1v8-ldo1 {
regulator-always-on;
};
+ vcc1v8_ldo2_reg: fixedregulator-vcc1v8-ldo2 {
+ compatible = "regulator-fixed";
+ regulator-name = "ldo2";
+ regulator-min-microvolt = <180>;
+ regulator-max-microvolt = <180>;
+ regulator-always-on;
+ };
+
hdmi: connector {
compatible = "hdmi-connector";
label = "hdmi";
@@ -58,6 +66,57 @@ hdmi_connector_in: endpoint {
};
};
};
+
+ sound0: sound@0 {
+ compatible = "simple-audio-card";
+ simple-audio-card,name = "K2G-EVM";
+ simple-audio-card,widgets =
+ "Headphone", "Headphone Jack",
+ "Line", "Line In";
+ simple-audio-card,routing =
+ "Headphone Jack", "HPLOUT",
+ "Headphone Jack", "HPROUT",
+ "LINE1L", "Line In",
+ "LINE1R", "Line In";
+
+ simple-audio-card,dai-link@0 {
+ format = "i2s";
+ bitclock-master = <_0_master>;
+ frame-master = <_0_master>;
+ sound0_0_master: cpu {
+ sound-dai = <>;
+ clocks = <_clks 0x6 1>;
+ system-clock-direction-out;
+ };
+
+ codec {
+ sound-dai = <>;
+ system-clock-frequency = <12288000>;
+ };
+ };
+
+ simple-audio-card,dai-link@1 {
+ format = "i2s";
+ bitclock-master = <_1_master>;
+ frame-master = <_1_master>;
+ sound0_1_master: cpu {
+ sound-dai = <>;
+ clocks = <_clks 0x6 1>;
+ system-clock-direction-out;
+ };
+
+ codec {
+ sound-dai = <>;
+ system-clock-frequency = <12288000>;
+ };
+ };
+ };
+
+ sii9022_mclk: sii9022_mclk {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <12288000>;
+ };
};
_pinctrl {
@@ -214,6 +273,15 @@ K2G_CORE_IOPAD(0x10e4) (BUFFER_CLASS_B | PULL_DISABLE |
MUX_MODE0) /* dssde.dssd
K2G_CORE_IOPAD(0x10e8) (BUFFER_CLASS_B | PULL_DISABLE |
MUX_MODE0) /* dssfid.dssfid */
>;
};
+
+ mcasp2_pins: pinmux_mcasp2_pins {
+ pinctrl-single,pins = <
+ K2G_CORE_IOPAD(0x1234) (BUFFER_CLASS_B | PIN_PULLDOWN |
MUX_MODE4) /* pr0_pru_gpo2.mcasp2_axr2 */
+ K2G_CORE_IOPAD(0x1238) (BUFFER_CLASS_B | PIN_PULLDOWN |
MUX_MODE4) /* pr0_pru_gpo3.mcasp2_axr3 */
+ K2G_CORE_IOPAD(0x1254) (BUFFER_CLASS_B | PIN_PULLDOWN |
MUX_MODE4) /* pr0_pru_gpo10.mcasp2_afsx */
+ K2G_CORE_IOPAD(0x125c) (BUFFER_CLASS_B | PIN_PULLDOWN |
MUX_MODE4) /* pr0_pru_gpo12.mcasp2_aclkx */
+ >;
+ };
};
{
@@ -423,6 +491,10 @@ sii9022: sii9022@3b {
compatible = "sil,sii9022";
reg = <0x3b>;
+ sil,i2s-data-lanes = < 0 >;
+ clocks = <_mclk>;
+ clock-names = "mclk";
+
ports {
#address-cells = <1>;
#size-cells = <0>;
@@ -444,6 +516,19 @@ sii9022_out: endpoint {
};
};
};
+
+ tlv320aic3106: tlv320aic3106@1b {
+ #sound-dai-cells = <0>;
+ compatible = "ti,tlv320aic3106";
+ reg = <0x1b>;
+ status
Re: [PATCH v6 3/3] dmaengine: qcom: Add GPI dma driver
Hi Vinod,
On 09/11/2020 10.54, Vinod Koul wrote:
> This controller provides DMAengine capabilities for a variety of peripheral
> buses such as I2C, UART, and SPI. By using GPI dmaengine driver, bus
> drivers can use a standardize interface that is protocol independent to
> transfer data between memory and peripheral.
There is something I don't quite follow regarding to tracking the issued
and in progress transfers...
...
> diff --git a/drivers/dma/qcom/gpi.c b/drivers/dma/qcom/gpi.c
> new file mode 100644
> index ..d2334f535de2
> --- /dev/null
> +++ b/drivers/dma/qcom/gpi.c
...
> +/* process DMA Immediate completion data events */
> +static void gpi_process_imed_data_event(struct gchan *gchan,
> + struct immediate_data_event *imed_event)
> +{
> + struct gpii *gpii = gchan->gpii;
> + struct gpi_ring *ch_ring = >ch_ring;
> + void *tre = ch_ring->base + (ch_ring->el_size * imed_event->tre_index);
> + struct dmaengine_result result;
> + struct gpi_desc *gpi_desc;
> + struct virt_dma_desc *vd;
> + unsigned long flags;
> + u32 chid;
> +
> + /*
> + * If channel not active don't process event
> + */
> + if (gchan->pm_state != ACTIVE_STATE) {
> + dev_err(gpii->gpi_dev->dev, "skipping processing event because
> ch @ %s state\n",
> + TO_GPI_PM_STR(gchan->pm_state));
> + return;
> + }
> +
> + spin_lock_irqsave(>vc.lock, flags);
> + vd = vchan_next_desc(>vc);
you take the first entry from the desc_issued list.
The one you actually started is the last one from the list.
> + if (!vd) {
> + struct gpi_ere *gpi_ere;
> + struct gpi_tre *gpi_tre;
> +
> + spin_unlock_irqrestore(>vc.lock, flags);
> + dev_dbg(gpii->gpi_dev->dev, "event without a pending
> descriptor!\n");
> + gpi_ere = (struct gpi_ere *)imed_event;
> + dev_dbg(gpii->gpi_dev->dev,
> + "Event: %08x %08x %08x %08x\n",
> + gpi_ere->dword[0], gpi_ere->dword[1],
> + gpi_ere->dword[2], gpi_ere->dword[3]);
> + gpi_tre = tre;
> + dev_dbg(gpii->gpi_dev->dev,
> + "Pending TRE: %08x %08x %08x %08x\n",
> + gpi_tre->dword[0], gpi_tre->dword[1],
> + gpi_tre->dword[2], gpi_tre->dword[3]);
> + return;
> + }
> + gpi_desc = to_gpi_desc(vd);
> + spin_unlock_irqrestore(>vc.lock, flags);
> +
> + /*
> + * RP pointed by Event is to last TRE processed,
> + * we need to update ring rp to tre + 1
> + */
> + tre += ch_ring->el_size;
> + if (tre >= (ch_ring->base + ch_ring->len))
> + tre = ch_ring->base;
> + ch_ring->rp = tre;
> +
> + /* make sure rp updates are immediately visible to all cores */
> + smp_wmb();
> +
> + chid = imed_event->chid;
> + if (imed_event->code == MSM_GPI_TCE_EOT && gpii->ieob_set) {
> + if (chid == GPI_RX_CHAN)
> + goto gpi_free_desc;
> + else
> + return;
> + }
> +
> + if (imed_event->code == MSM_GPI_TCE_UNEXP_ERR)
> + result.result = DMA_TRANS_ABORTED;
> + else
> + result.result = DMA_TRANS_NOERROR;
> + result.residue = gpi_desc->len - imed_event->length;
> +
> + dma_cookie_complete(>tx);
> + dmaengine_desc_get_callback_invoke(>tx, );
> +
> +gpi_free_desc:
> + spin_lock_irqsave(>vc.lock, flags);
> + list_del(>node);
> + spin_unlock_irqrestore(>vc.lock, flags);
> + kfree(gpi_desc);
> + gpi_desc = NULL;
> +}
> +
> +/* processing transfer completion events */
> +static void gpi_process_xfer_compl_event(struct gchan *gchan,
> + struct xfer_compl_event *compl_event)
> +{
> + struct gpii *gpii = gchan->gpii;
> + struct gpi_ring *ch_ring = >ch_ring;
> + void *ev_rp = to_virtual(ch_ring, compl_event->ptr);
> + struct virt_dma_desc *vd;
> + struct gpi_desc *gpi_desc;
> + struct dmaengine_result result;
> + unsigned long flags;
> + u32 chid;
> +
> + /* only process events on active channel */
> + if (unlikely(gchan->pm_state != ACTIVE_STATE)) {
> + dev_err(gpii->gpi_dev->dev, "skipping processing event because
> ch @ %s state\n",
> + TO_GPI_PM_STR(gchan->pm_state));
> + return;
> + }
> +
> + spin_lock_irqsave(>vc.lock, flags);
> + vd = vchan_next_desc(>vc);
you take the first entry from the desc_issued list here as well.
The one you actually started is the last one from the list.
> + if (!vd) {
> + struct gpi_ere *gpi_ere;
> +
> + spin_unlock_irqrestore(>vc.lock, flags);
> + dev_err(gpii->gpi_dev->dev, "Event without a pending
> descriptor!\n");
> + gpi_ere = (struct gpi_ere *)compl_event;
> +
Re: [PATCH v3 0/4] ASoC: pcm512x: Patch series to set fmt from `set_fmt()`
Kirill, On 15/11/2020 14.23, Kirill Marinushkin wrote: > Set format from `set_fmt()` func instead of `hw_params()`, plus supportive > commits Thank you for the clean series! Reviewed-by: Peter Ujfalusi > Kirill Marinushkin (4): > ASoC: pcm512x: Fix not setting word length if DAIFMT_CBS_CFS > ASoC: pcm512x: Rearrange operations in `hw_params()` > ASoC: pcm512x: Move format check into `set_fmt()` > ASoC: pcm512x: Add support for more data formats > > sound/soc/codecs/pcm512x.c | 134 > - > 1 file changed, 84 insertions(+), 50 deletions(-) > - Péter Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
Re: [PATCH] ASoC: pcm512x: Add support for data formats RJ and LJ
Hi Kirill, On 12/11/2020 9.57, Kirill Marinushkin wrote: >> The set_fmt callback is there to set the bus format, it has nothing to >> do (in most cases) with the sample format (hw_params). Bus coding, clock >> source has nothing to do with hw_params. >> >> When you bind a link you will use set_fmt for the two sides to see if >> they can agree, that both can support what has been asked. >> >> The pcm512x driver just saves the fmt and say back to that card: >> whatever, I'm fine with it. But runtime during hw_params it can fail due >> to unsupported bus format, which it actually acked to be ok. >> >> This is the difference. >> >> Sure, some device have constraint based on the fmt towards the hw_params >> and it is perfectly OK to do such a checks and rejections or build >> rules/constraints based on fmt, but failing hw_params just because >> set_fmt did not checked that the bus format is not even supported is not >> a nice thing to do. > > Those are good arguments > >>> Would you agree? >> >> I don't have a device to test, I'm just trying to point out what is the >> right thing to do. > > I have a device to test. I will move format checks into `pcm512x_set_fmt()`, > ensure that it works properly, and submit as patch v3. Thank you. I know it is slightly more work. When you send v3 please do not use --in-reply-to, let it be itself. Regards, - Péter Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
Re: [PATCH] ASoC: pcm512x: Add support for data formats RJ and LJ
Hi Kirill,
On 11/11/2020 9.54, Kirill Marinushkin wrote:
> Hello Peter,
>
> than you for your review!
>
>> The bus format and
>>
>>> switch (pcm512x->fmt & SND_SOC_DAIFMT_MASTER_MASK) {
>>
>>> case SND_SOC_DAIFMT_CBS_CFS:
>>> ret = regmap_update_bits(pcm512x->regmap,
>>
>> the clock generation role should be set in pcm512x_set_fmt(), in that
>> way you can deny specific setups earlier.
>
> I think we could move both checks for`SND_SOC_DAIFMT_FORMAT_MASK` and
> `SND_SOC_DAIFMT_MASTER_MASK` into `pcm512x_set_fmt()`. But it would be a
> different scope, and I didn't intend to do that level of refactoring.
Right, I was just saying what would make sense.
> Looking at other codecs in kernel, I would say, that doing those checks in
> `pcm512x_hw_params()`, as they are done currently, is an equally valid
> approach.
The exception proves the rule
> As technically keeping checs where they are now doesn't break anything
They are just in a wrong place.
> and is
> aligned with ASoC codecs design, I suggest to keep the checks where they are.
The set_fmt callback is there to set the bus format, it has nothing to
do (in most cases) with the sample format (hw_params). Bus coding, clock
source has nothing to do with hw_params.
When you bind a link you will use set_fmt for the two sides to see if
they can agree, that both can support what has been asked.
The pcm512x driver just saves the fmt and say back to that card:
whatever, I'm fine with it. But runtime during hw_params it can fail due
to unsupported bus format, which it actually acked to be ok.
This is the difference.
Sure, some device have constraint based on the fmt towards the hw_params
and it is perfectly OK to do such a checks and rejections or build
rules/constraints based on fmt, but failing hw_params just because
set_fmt did not checked that the bus format is not even supported is not
a nice thing to do.
> Would you agree?
I don't have a device to test, I'm just trying to point out what is the
right thing to do.
I don't buy the argument that the sequencing is important here for the
register writes. The fmt is set only once and those registers will be
only written once.
>> I would also add DSP_A and DSP_B modes at the same time, DSP_A would
>> need a write of 1 to register 41 (PCM512x_I2S_2, offset = 1), other
>> formats should set the offset to 0.
>
> That's a good idea, than you for technical details! I just didn't know how to
> use DSP_A and DSP_B. I will add them, and submit as patch v2
Great!
Thanks
- Péter
> Best regards,
> Kirill
>
> On 11/10/2020 07:59 AM, Peter Ujfalusi wrote:
>>
>>
>> On 09/11/2020 23.21, Kirill Marinushkin wrote:
>>> Currently, pcm512x driver supports only I2S data format.
>>> This commit adds RJ and LJ as well.
>>>
>>> I don't expect regression WRT existing sound cards, because:
>>>
>>> * default value in corresponding register of pcm512x codec is 0 == I2S
>>> * existing in-tree sound cards with pcm512x codec are configured for I2S
>>> * i don't see how existing off-tree sound cards with pcm512x codec could be
>>> configured differently - it would not work
>>> * tested explicitly, that there is no regression with Raspberry Pi +
>>> sound card `sound/soc/bcm/hifiberry_dacplus.c`
>>>
>>> Signed-off-by: Kirill Marinushkin
>>> Cc: Mark Brown
>>> Cc: Takashi Iwai
>>> Cc: Liam Girdwood
>>> Cc: Matthias Reichl
>>> Cc: Kuninori Morimoto
>>> Cc: Peter Ujfalusi
>>> Cc: alsa-de...@alsa-project.org
>>> Cc: linux-kernel@vger.kernel.org
>>> ---
>>> sound/soc/codecs/pcm512x.c | 24
>>> 1 file changed, 24 insertions(+)
>>>
>>> diff --git a/sound/soc/codecs/pcm512x.c b/sound/soc/codecs/pcm512x.c
>>> index 8153d3d01654..c6e975fb4a43 100644
>>> --- a/sound/soc/codecs/pcm512x.c
>>> +++ b/sound/soc/codecs/pcm512x.c
>>> @@ -1167,6 +1167,7 @@ static int pcm512x_hw_params(struct snd_pcm_substream
>>> *substream,
>>> struct snd_soc_component *component = dai->component;
>>> struct pcm512x_priv *pcm512x = snd_soc_component_get_drvdata(component);
>>> int alen;
>>> + int afmt;
>>> int gpio;
>>> int clock_output;
>>> int master_mode;
>>> @@ -1195,6 +1196,22 @@ static int pcm512x_hw_params(struct
>>> snd_pcm_substream *substream,
>>> return -EINVAL;
>>> }
>>>
>>> + switch (pcm512x->fmt & SND_SOC_DAIFMT_FORMAT_MASK) {
>>> + case SND_SOC_DAIFMT_I2S:
&
Re: [PATCH] ASoC: pcm512x: Add support for data formats RJ and LJ
On 09/11/2020 23.21, Kirill Marinushkin wrote:
> Currently, pcm512x driver supports only I2S data format.
> This commit adds RJ and LJ as well.
>
> I don't expect regression WRT existing sound cards, because:
>
> * default value in corresponding register of pcm512x codec is 0 == I2S
> * existing in-tree sound cards with pcm512x codec are configured for I2S
> * i don't see how existing off-tree sound cards with pcm512x codec could be
> configured differently - it would not work
> * tested explicitly, that there is no regression with Raspberry Pi +
> sound card `sound/soc/bcm/hifiberry_dacplus.c`
>
> Signed-off-by: Kirill Marinushkin
> Cc: Mark Brown
> Cc: Takashi Iwai
> Cc: Liam Girdwood
> Cc: Matthias Reichl
> Cc: Kuninori Morimoto
> Cc: Peter Ujfalusi
> Cc: alsa-de...@alsa-project.org
> Cc: linux-kernel@vger.kernel.org
> ---
> sound/soc/codecs/pcm512x.c | 24
> 1 file changed, 24 insertions(+)
>
> diff --git a/sound/soc/codecs/pcm512x.c b/sound/soc/codecs/pcm512x.c
> index 8153d3d01654..c6e975fb4a43 100644
> --- a/sound/soc/codecs/pcm512x.c
> +++ b/sound/soc/codecs/pcm512x.c
> @@ -1167,6 +1167,7 @@ static int pcm512x_hw_params(struct snd_pcm_substream
> *substream,
> struct snd_soc_component *component = dai->component;
> struct pcm512x_priv *pcm512x = snd_soc_component_get_drvdata(component);
> int alen;
> + int afmt;
> int gpio;
> int clock_output;
> int master_mode;
> @@ -1195,6 +1196,22 @@ static int pcm512x_hw_params(struct snd_pcm_substream
> *substream,
> return -EINVAL;
> }
>
> + switch (pcm512x->fmt & SND_SOC_DAIFMT_FORMAT_MASK) {
> + case SND_SOC_DAIFMT_I2S:
> + afmt = PCM512x_AFMT_I2S;
> + break;
> + case SND_SOC_DAIFMT_RIGHT_J:
> + afmt = PCM512x_AFMT_RTJ;
> + break;
> + case SND_SOC_DAIFMT_LEFT_J:
> + afmt = PCM512x_AFMT_LTJ;
> + break;
> + default:
> + dev_err(component->dev, "unsupported DAI format: 0x%x\n",
> + pcm512x->fmt);
> + return -EINVAL;
> + }
> +
The bus format and
> switch (pcm512x->fmt & SND_SOC_DAIFMT_MASTER_MASK) {
> case SND_SOC_DAIFMT_CBS_CFS:
> ret = regmap_update_bits(pcm512x->regmap,
the clock generation role should be set in pcm512x_set_fmt(), in that
way you can deny specific setups earlier.
I would also add DSP_A and DSP_B modes at the same time, DSP_A would
need a write of 1 to register 41 (PCM512x_I2S_2, offset = 1), other
formats should set the offset to 0.
> @@ -1236,6 +1253,13 @@ static int pcm512x_hw_params(struct snd_pcm_substream
> *substream,
> return ret;
> }
>
> + ret = regmap_update_bits(pcm512x->regmap, PCM512x_I2S_1,
> + PCM512x_AFMT, afmt);
> + if (ret != 0) {
> + dev_err(component->dev, "Failed to set data format: %d\n", ret);
> + return ret;
> + }
> +
> if (pcm512x->pll_out) {
> ret = regmap_write(pcm512x->regmap, PCM512x_FLEX_A, 0x11);
> if (ret != 0) {
>
- Péter
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
Re: [PATCH 01/18] dmaengine: of-dma: Add support for optional router configuration callback
On 09/11/2020 14.23, Vinod Koul wrote: > HI Peter, > > On 09-11-20, 14:09, Peter Ujfalusi wrote: >> Hi Vinod, >> >> On 09/11/2020 13.45, Vinod Koul wrote: >>>> Without a channel number I can not do anything. >>>> It is close to a chicken and egg problem. >>> >>> We get 'channel' in xlate, so wont that help? I think I am still missing >>> something here :( >> >> Yes, we get channel in xlate, but we get the channel after >> ofdma->of_dma_route_allocate() > > That is correct, so you need this info in allocate somehow.. To know the event number the router must send to trigger the channel I need the router to 'craft' the dmaspec which can be used to request the channel. To request a bcdma channel to be triggered by global trigger 0: [A] <_bcdma 1 0 15> main_bcdma - phandle to BCDMA 1 - triggered by global trigger0 0 - ignored 15 - ASEL value A peripheral can not really use this binding directly as we need to configure the get the event to be sent to the given channel's trigger0. The binding for the router (l2g if INTA in this case): [B] <_l2g 21 0 15> inta_l2g - phandle to therouter 21 - local event index (input event/signal) 0 - event detection mode (pulsed/rising) 15 - ASEL value The of_dma_router_xlate() receives the dmaspec for [B}, the router driver creates the dmaspec for [A]. The xlate can not request the channel first as it needs the dmaspec from the router to do so. - Péter Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
Re: [PATCH 01/18] dmaengine: of-dma: Add support for optional router configuration callback
Hi Vinod, On 09/11/2020 13.45, Vinod Koul wrote: >> Without a channel number I can not do anything. >> It is close to a chicken and egg problem. > > We get 'channel' in xlate, so wont that help? I think I am still missing > something here :( Yes, we get channel in xlate, but we get the channel after ofdma->of_dma_route_allocate() of_dma_route_allocate() si the place where DMA routers create the dmaspec for the DMA controller to get a channel and they up until BCDMA did also the HW configuration to get the event routed. For a BCDMA channel we can have three triggers: Global trigger 0 for the channel Global trigger 1 for the channel Local trigger for the channel Every BCDMA channel have these triggers and for all of them they are the same (from the channel's pow). bchan0 can be triggered by global trigger 0 bchan1 can be triggered by global trigger 0 But these triggers are not the same ones, the real trigger depends on the router, which of it's input is converted to send out an event to trigger bchan0_trigger0 or to trigger bchan1_trigger0. When we got the channel with the dmaspec from the router driver then we need to tell the router driver that it needs to send a given event in order to trigger the channel that we got. We can not have traditional binding for BCDMA either where we would tell the bchan index to be used because depending on the resource allocation done within sysfw that exact channel might not be even available for us. - Péter Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
Re: [PATCH 2/4] arm64: dts: ti: k3-j721e*: Cleanup disabled nodes at SoC dtsi level
On 06/11/2020 23.46, Nishanth Menon wrote: > On 13:32-20201106, Peter Ujfalusi wrote: > [...] >>> >>>> >>>>> default power management functionality etc >>>> >>>> Right, so how does that helps with devices present in the SoC, but no >>>> node at all? First thing which comes to mind is AASRC, we don't have >>>> Linux driver for it (and no DT binding document), but that does not mean >>>> that it is not present. How PM would take that into account? >>> >>> I think we are mixing topics here -> I was stating the motivation why >>> devicetree chose such as default. >> >> I don't question the fact that 'okay' is the default status if it is not >> explicitly present. There is no better default than that. > > ^^ -> Alright, that is all we are trying to do here: defaults in the > SoC.dtsi and specific cleanups (firmware reserved / board unused > disables) be done in a common board.dtsi (for now, there is no such > specific need, I guess). The default is what it is: default choice which suits most of the nodes. If the node is not complete in it's present form then it is not in it's default state. imho. >>> Alright - what do we suggest we do? >> >> Not sure, I'm 'whatever' after [1] makes it to mainline or next. > [] >> [1] >> https://lore.kernel.org/alsa-devel/20201106072551.689-1-peter.ujfal...@ti.com/ > > > I don't see the relationship between the series.. I think this series > brings no change in dtb, hence with OR without your driver cleanup > series, there is no practical regressions. This series opens up the possibility of nodes leaking to dtb with known broken state and the driver should have a better strategy than 'works by luck' to handle it ;) >> >>> Tony, Rob - I need some guidance here. >> >> I'm fine whatever way we take, but I think it is up to you to make the >> call as the maintainer of the TI dts files... ;) > > Yep - I have'nt seen a reason yet that must cause us to change from the > Device tree default approach in our debates. Imho 'disabled' is the default for nodes like McASP as it is: "Indicates that the device is not presently operational, but it might become operational in the future" (for example, needed properties added to the node). >>>> There is no such a tag, but: >>>> whatever-by: Peter Ujfalusi >>> >>> OK - I have no idea how B4 or patchworks pick that one as :D >> >> If we take this road, than I'm okay with it, but I'm going to take >> silent protest (not sending acked-by or revired-by). >> That should not stop you doing what you believe is best for the future! > > OK - thanks for your review and the discussions, always appreciate > getting our views out there. > > if there are no other comments, I will try and post a v2 over the > weekend. OK - Péter Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
Re: [PATCH 2/4] arm64: dts: ti: k3-j721e*: Cleanup disabled nodes at SoC dtsi level
Nishanth, On 05/11/2020 16.08, Nishanth Menon wrote: > On 09:32-20201105, Peter Ujfalusi wrote: >> Nishanth, >> >> On 05/11/2020 0.43, Nishanth Menon wrote: >>> The device tree standard sets the default node behavior when status >>> property as enabled. >> >> It should be: >> When the status property is not present under a node, the "okay' value >> is assumed. > > Thanks.. will update. > >> >> Note: the device tree specification does not document default value as >> such, see v0.3 (2.3.4, page 14). >> Yes, the "okay" is used in case the status property is missing (by Linux >> at least). > > Maybe the spec update needs a formal release? Kumar's patch is merged: > https://github.com/devicetree-org/devicetree-specification/pull/33 > > on that exact same section, which you can see > https://github.com/devicetree-org/devicetree-specification/blob/master/source/chapter2-devicetree-basics.rst I stand correct, I only checked the released version. > Brings it to sync to: > https://elinux.org/Device_Tree_Linux#status_property > >> >>> There are many reasons for doing the same, number >>> of strings in device tree, >> >> with expense of loc and readability. > > The "readability" part is subjective a bit.. enabled and disabled both > have verbosity problem lets see how we can optimize as new boards come > in. I agree. > >> >>> default power management functionality etc >> >> Right, so how does that helps with devices present in the SoC, but no >> node at all? First thing which comes to mind is AASRC, we don't have >> Linux driver for it (and no DT binding document), but that does not mean >> that it is not present. How PM would take that into account? > > I think we are mixing topics here -> I was stating the motivation why > devicetree chose such as default. I don't question the fact that 'okay' is the default status if it is not explicitly present. There is no better default than that. > Do we have a suggestion to improve > the description in the commit? A bit later on that. >> >>> are few of the reasons. >>> >>> In general, after a few rounds of discussions [1] there are few >>> options one could take when dealing with SoC dtsi and board dts >>> >>> a. SoC dtsi provide nodes as a super-set default (aka enabled) state and >>>to prevent messy board files, when more boards are added per SoC, we >>>optimize and disable commonly un-used nodes in board-common.dtsi >>> b. SoC dtsi disables all hardware dependent nodes by default and board >>>dts files enable nodes based on a need basis. >>> c. Subjectively pick and choose which nodes we will disable by default >>>in SoC dtsi and over the years we can optimize things and change >>>default state depending on the need. >> >> For the record: c was not really an option. There were no subjectivity, >> the reason was pragmatic. > > > (c) some examples where we did pick that option (fixes): > https://lore.kernel.org/linux-arm-kernel/20201104224356.18040-4...@ti.com/ > https://lore.kernel.org/linux-arm-kernel/20201104224356.18040-5...@ti.com/ this is different, these patches just removing the "status = 'okay';" lines where they are not needed and can be omitted to save few lines and it does help on readablity. >> The reason why we kept McASP nodes (and dss) disabled in the soc dtsi >> file is that they are not operation in the form they present in there. >> They _need_ additional properties to be operational and those properties >> can only be added in the board dts file. > > I dont think we are changing anything in the output dtb files, Correct, the resulted dtb is identical. If the developer for upcoming boards did check the schematics vs TRM vs dtsi and spot the things that is not configured. dtb check will complain when it is starting to check against the documentation, but McASP is not yet converted to yaml and to be honest I don't want to convert the current binding to be the binding. When it was done it just moved pdata variables to DT and that was wrong. This is off-topic a bit. > we are > just leaving the defaults as dt defaults and set the disable state in > board dts OR common board dtsi. Yes, we leave the non working/configured node 'okay' in dtsi and expect that the board file author will know which node must be disabled because it is incomplete. >> This is not remotely a subjective view, this is the opposite of >> subjectivity. > > the usage of McASP was'nt meant as (c).. it is (b). is there a better way > to describe this i
Re: [PATCH 2/4] arm64: dts: ti: k3-j721e*: Cleanup disabled nodes at SoC dtsi level
Nishanth,
On 05/11/2020 0.43, Nishanth Menon wrote:
> The device tree standard sets the default node behavior when status
> property as enabled.
It should be:
When the status property is not present under a node, the "okay' value
is assumed.
Note: the device tree specification does not document default value as
such, see v0.3 (2.3.4, page 14).
Yes, the "okay" is used in case the status property is missing (by Linux
at least).
> There are many reasons for doing the same, number
> of strings in device tree,
with expense of loc and readability.
> default power management functionality etc
Right, so how does that helps with devices present in the SoC, but no
node at all? First thing which comes to mind is AASRC, we don't have
Linux driver for it (and no DT binding document), but that does not mean
that it is not present. How PM would take that into account?
> are few of the reasons.
>
> In general, after a few rounds of discussions [1] there are few
> options one could take when dealing with SoC dtsi and board dts
>
> a. SoC dtsi provide nodes as a super-set default (aka enabled) state and
>to prevent messy board files, when more boards are added per SoC, we
>optimize and disable commonly un-used nodes in board-common.dtsi
> b. SoC dtsi disables all hardware dependent nodes by default and board
>dts files enable nodes based on a need basis.
> c. Subjectively pick and choose which nodes we will disable by default
>in SoC dtsi and over the years we can optimize things and change
>default state depending on the need.
For the record: c was not really an option. There were no subjectivity,
the reason was pragmatic.
We are all familiar with the Devicetree specification, but let me quote
from chapter 2.3.4:
"okay"
Indicates the device is operational.
"disabled"
Indicates that the device is not presently operational, but it might
become operational in the future (for example, something is not plugged
in, or switched off).
Refer to the device binding for details on what disabled means for a
given device.
The reason why we kept McASP nodes (and dss) disabled in the soc dtsi
file is that they are not operation in the form they present in there.
They _need_ additional properties to be operational and those properties
can only be added in the board dts file.
This is not remotely a subjective view, this is the opposite of
subjectivity.
As for things not owned by the OS we have the "reserved" status.
> While there are pros and cons on each of these approaches, the right
> thing to do will be to stick with device tree default standards and
> work within those established rules. So, we choose to go with option
> (a).
>
> Lets cleanup defaults of j721e SoC dtsi before this gets more harder
> to cleanup later on and new SoCs are added.
>
> The only functional difference between the dtb generated is
> status='okay' is no longer necessary for mcasp10 and depends on the
> default state.
>
> [1]
> https://lore.kernel.org/linux-arm-kernel/20201027130701.ge5...@atomide.com/
>
> Fixes: 1c4d35265fb2 ("arm64: dts: ti: k3-j721e-main: Add McASP nodes")
> Fixes: 76921f15acc0 ("arm64: dts: ti: k3-j721e-main: Add DSS node")
> Cc: Jyri Sarha
> Cc: Tomi Valkeinen
> Cc: Peter Ujfalusi
> Cc: Tony Lindgren
> Signed-off-by: Nishanth Menon
> ---
> .../dts/ti/k3-j721e-common-proc-board.dts | 48 ++-
> arch/arm64/boot/dts/ti/k3-j721e-main.dtsi | 26 --
> 2 files changed, 47 insertions(+), 27 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/ti/k3-j721e-common-proc-board.dts
> b/arch/arm64/boot/dts/ti/k3-j721e-common-proc-board.dts
> index 52e121155563..9416528caa8a 100644
> --- a/arch/arm64/boot/dts/ti/k3-j721e-common-proc-board.dts
> +++ b/arch/arm64/boot/dts/ti/k3-j721e-common-proc-board.dts
> @@ -540,6 +540,46 @@ {
><_clks 152 18>; /* PLL23_HSDIV0 */
> };
>
> + {
> + status = "disabled";
> +};
> +
> + {
> + status = "disabled";
> +};
> +
> + {
> + status = "disabled";
> +};
> +
> + {
> + status = "disabled";
> +};
> +
> + {
> + status = "disabled";
> +};
> +
> + {
> + status = "disabled";
> +};
> +
> + {
> + status = "disabled";
> +};
> +
> + {
> + status = "disabled";
> +};
> +
> + {
> + status = "disabled";
> +};
> +
> + {
> + status = "disabled";
> +};
> +
> {
> #sound-dai-cells = <0>;
>
> @@ -556,8 +596,10 @@ {
> >;
> tx-num-evt = <0>;
> rx-num-evt = <0>;
> +};
&
[tip: irq/urgent] dt-bindings: irqchip: ti, sci-inta: Fix diagram indentation for unmapped events
The following commit has been merged into the irq/urgent branch of tip:
Commit-ID: 82768a86c64659c7181571ebfbc41ec9f2e52dde
Gitweb:
https://git.kernel.org/tip/82768a86c64659c7181571ebfbc41ec9f2e52dde
Author:Peter Ujfalusi
AuthorDate:Tue, 03 Nov 2020 15:50:04 +02:00
Committer: Thomas Gleixner
CommitterDate: Tue, 03 Nov 2020 16:25:55 +01:00
dt-bindings: irqchip: ti, sci-inta: Fix diagram indentation for unmapped events
One space has been missing by the diagram update.
Fixes: bb2bd7c7f3d0 ("dt-bindings: irqchip: ti, sci-inta: Update for unmapped
event handling")
Reported-by: Rob Herring
Signed-off-by: Peter Ujfalusi
Signed-off-by: Thomas Gleixner
Acked-by: Rob Herring
Cc: Marc Zyngier
Link: https://lore.kernel.org/r/20201103135004.2363-1-peter.ujfal...@ti.com
---
Documentation/devicetree/bindings/interrupt-controller/ti,sci-inta.yaml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
a/Documentation/devicetree/bindings/interrupt-controller/ti,sci-inta.yaml
b/Documentation/devicetree/bindings/interrupt-controller/ti,sci-inta.yaml
index cc79549..8d90bc5 100644
--- a/Documentation/devicetree/bindings/interrupt-controller/ti,sci-inta.yaml
+++ b/Documentation/devicetree/bindings/interrupt-controller/ti,sci-inta.yaml
@@ -34,7 +34,7 @@ description: |
| |
| Unmap |
| +--+|
- Unmapped events ->| | umapidx|->
Globalevents
+ Unmapped events >| | umapidx|->
Globalevents
| +--+|
| |
+-+
Re: [GIT PULL] irqchip updates for 5.10, take #1
Rob, On 03/11/2020 15.39, Rob Herring wrote: > On Sun, Nov 1, 2020 at 6:22 AM Marc Zyngier wrote: >> >> Hi Thomas, >> >> Here's a smallish set of fixes for 5.10. Some fixes after the >> IPI-as-IRQ (I expect a couple more next week), two significant bug >> fixes for the SiFive PLIC, and a TI update to handle their "unmapped >> events". The rest is the usual set of cleanups and tidying up. >> >> Please pull, >> >> M. >> >> The following changes since commit 63ea38a402213d8c9c16e58ee4901ff51bc8fe3c: >> >> Merge branch 'irq/mstar' into irq/irqchip-next (2020-10-10 12:46:54 +0100) >> >> are available in the Git repository at: >> >> git://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git >> tags/irqchip-fixes-5.10-1 >> >> for you to fetch changes up to d95bdca75b3fb41bf185efe164e05aed820081a5: >> >> irqchip/ti-sci-inta: Add support for unmapped event handling (2020-11-01 >> 12:00:50 +) >> >> >> irqchip fixes for Linux 5.10, take #1 >> >> - A couple of fixes after the IPI as IRQ patches (Kconfig, bcm2836) >> - Two SiFive PLIC fixes (irq_set_affinity, hierarchy handling) >> - "unmapped events" handling for the ti-sci-inta controller >> - Tidying up for the irq-mst driver (static functions, Kconfig) >> - Small cleanup in the Renesas irqpin driver >> - STM32 exti can now handle LP timer events >> >> >> Fabrice Gasnier (1): >> irqchip/stm32-exti: Add all LP timer exti direct events support >> >> Geert Uytterhoeven (2): >> irqchip/mst: MST_IRQ should depend on ARCH_MEDIATEK or ARCH_MSTARV7 >> irqchip/renesas-intc-irqpin: Merge irlm_bit and needs_irlm >> >> Greentime Hu (2): >> irqchip/sifive-plic: Fix broken irq_set_affinity() callback >> irqchip/sifive-plic: Fix chip_data access within a hierarchy >> >> Marc Zyngier (4): >> genirq: Let GENERIC_IRQ_IPI select IRQ_DOMAIN_HIERARCHY >> irqchip/mst: Make mst_intc_of_init static >> irqchip/mips: Drop selection of IRQ_DOMAIN_HIERARCHY >> irqchip/bcm2836: Fix missing __init annotation >> >> Peter Ujfalusi (2): >> dt-bindings: irqchip: ti, sci-inta: Update for unmapped event handling > > This breaks dt_binding_check in linux-next: > > Traceback (most recent call last): > File "/usr/local/bin/dt-extract-example", line 45, in > binding = yaml.load(open(args.yamlfile, encoding='utf-8').read()) > File "/usr/local/lib/python3.8/dist-packages/ruamel/yaml/main.py", > line 343, in load > return constructor.get_single_data() > File "/usr/local/lib/python3.8/dist-packages/ruamel/yaml/constructor.py", > line 111, in get_single_data > node = self.composer.get_single_node() > File "_ruamel_yaml.pyx", line 706, in _ruamel_yaml.CParser.get_single_node > File "_ruamel_yaml.pyx", line 724, in _ruamel_yaml.CParser._compose_document > File "_ruamel_yaml.pyx", line 775, in _ruamel_yaml.CParser._compose_node > File "_ruamel_yaml.pyx", line 891, in > _ruamel_yaml.CParser._compose_mapping_node > File "_ruamel_yaml.pyx", line 904, in _ruamel_yaml.CParser._parse_next_event > ruamel.yaml.parser.ParserError: while parsing a block mapping > in "", line 4, column 1 > did not find expected key > in "", line 37, column 2 > make[1]: *** [Documentation/devicetree/bindings/Makefile:20: > Documentation/devicetree/bindings/interrupt-controller/ti,sci-inta.example.dts] > Error 1 > make[1]: *** Deleting file > 'Documentation/devicetree/bindings/interrupt-controller/ti,sci-inta.example.dts' > ./Documentation/devicetree/bindings/interrupt-controller/ti,sci-inta.yaml:37:2: > [error] syntax error: expected , but found '' > (syntax) > > Looks like it's the block diagram change which needs more indentation. Sorry, I have sent a fix: https://lore.kernel.org/lkml/20201103135004.2363-1-peter.ujfal...@ti.com/ > > Rob > - Péter Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
[PATCH] dt-bindings: irqchip: ti, sci-inta: Fix diagram indentation for unmapped events
One space has been missing by the diagram update.
Fixes: bb2bd7c7f3d0 ("dt-bindings: irqchip: ti, sci-inta: Update for unmapped
event handling")
Reported-by: Rob Herring
Signed-off-by: Peter Ujfalusi
---
Hi,
I'm very sorry, I did not realized the missing whitespace in the original patch
and obviously I failed to run the check.
Regards,
Peter
.../devicetree/bindings/interrupt-controller/ti,sci-inta.yaml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
a/Documentation/devicetree/bindings/interrupt-controller/ti,sci-inta.yaml
b/Documentation/devicetree/bindings/interrupt-controller/ti,sci-inta.yaml
index be5f06f0044b..b5af12011499 100644
--- a/Documentation/devicetree/bindings/interrupt-controller/ti,sci-inta.yaml
+++ b/Documentation/devicetree/bindings/interrupt-controller/ti,sci-inta.yaml
@@ -34,7 +34,7 @@ description: |
| |
| Unmap |
| +--+|
- Unmapped events ->| | umapidx|->
Globalevents
+ Unmapped events >| | umapidx|->
Globalevents
| +--+|
| |
+-+
--
Peter
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
Re: [PATCH] thermal: ti-soc-thermal: Disable the CPU PM notifier for OMAP4430
Eduardo, Keerthy, On 29/10/2020 12.51, Tony Lindgren wrote: > * Peter Ujfalusi [201029 10:03]: >> Disabling the notifier fixes the random shutdowns on OMAP4430 (ES2.0 and >> ES2.1) >> but it does not cause any issues on OMAP4460 (PandaES) or OMAP3630 >> (BeagleXM). >> Tony's duovero with OMAP4430 ES2.3 did not ninja-shutdown, but he also have >> constant and steady stream of: >> thermal thermal_zone0: failed to read out thermal zone (-5) > > Works for me and I've verified duovero still keeps hitting core ret idle: Can you pick this one up for 5.10 to make omap4430-sdp to be usable (to not shut down randomly). The regression was introduced in 5.10-rc1. > Tested-by: Tony Lindgren > > Regards, > > Tony > - Péter Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
Re: [PATCH] ASoC: ti: davinci-evm: Remove redundant null check before clk_disable_unprepare
On 29/10/2020 10.25, Xu Wang wrote: > Because clk_disable_unprepare() already checked NULL clock parameter, > so the additional check is unnecessary, just remove it. Acked-by: Peter Ujfalusi > Signed-off-by: Xu Wang > --- > sound/soc/ti/davinci-evm.c | 3 +-- > 1 file changed, 1 insertion(+), 2 deletions(-) > > diff --git a/sound/soc/ti/davinci-evm.c b/sound/soc/ti/davinci-evm.c > index 105e56ab9cdc..b043a0070d20 100644 > --- a/sound/soc/ti/davinci-evm.c > +++ b/sound/soc/ti/davinci-evm.c > @@ -46,8 +46,7 @@ static void evm_shutdown(struct snd_pcm_substream > *substream) > struct snd_soc_card_drvdata_davinci *drvdata = > snd_soc_card_get_drvdata(soc_card); > > - if (drvdata->mclk) > - clk_disable_unprepare(drvdata->mclk); > + clk_disable_unprepare(drvdata->mclk); > } > > static int evm_hw_params(struct snd_pcm_substream *substream, > - Péter Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
Re: [PATCH] dmaengine: ti: k3-udma-glue: move psi-l pairing in channel en/dis functions
On 30/10/2020 22.30, Grygorii Strashko wrote:
> The NAVSS UDMA will stuck if target IP module is disabled by PM while PSI-L
> threads are paired UDMA<->IP and no further transfers is possible. This
> could be the case for IPs J721E Main CPSW (cpsw9g).
>
> Hence, to avoid such situation do PSI-L threads pairing only when UDMA
> channel is going to be enabled as at this time DMA consumer module expected
> to be active already.
Is this patch on top of the AM64 (BCDMA/PKTDMA) series or not?
Will it cause any conflict?
Acked-by: Peter Ujfalusi
> Signed-off-by: Grygorii Strashko
> ---
> drivers/dma/ti/k3-udma-glue.c | 64 +--
> 1 file changed, 38 insertions(+), 26 deletions(-)
>
> diff --git a/drivers/dma/ti/k3-udma-glue.c b/drivers/dma/ti/k3-udma-glue.c
> index a367584f0d7b..dfb65e382ab9 100644
> --- a/drivers/dma/ti/k3-udma-glue.c
> +++ b/drivers/dma/ti/k3-udma-glue.c
> @@ -303,19 +303,6 @@ struct k3_udma_glue_tx_channel
> *k3_udma_glue_request_tx_chn(struct device *dev,
> goto err;
> }
>
> - ret = xudma_navss_psil_pair(tx_chn->common.udmax,
> - tx_chn->common.src_thread,
> - tx_chn->common.dst_thread);
> - if (ret) {
> - dev_err(dev, "PSI-L request err %d\n", ret);
> - goto err;
> - }
> -
> - tx_chn->psil_paired = true;
> -
> - /* reset TX RT registers */
> - k3_udma_glue_disable_tx_chn(tx_chn);
> -
> k3_udma_glue_dump_tx_chn(tx_chn);
>
> return tx_chn;
> @@ -378,6 +365,18 @@ EXPORT_SYMBOL_GPL(k3_udma_glue_pop_tx_chn);
>
> int k3_udma_glue_enable_tx_chn(struct k3_udma_glue_tx_channel *tx_chn)
> {
> + int ret;
> +
> + ret = xudma_navss_psil_pair(tx_chn->common.udmax,
> + tx_chn->common.src_thread,
> + tx_chn->common.dst_thread);
> + if (ret) {
> + dev_err(tx_chn->common.dev, "PSI-L request err %d\n", ret);
> + return ret;
> + }
> +
> + tx_chn->psil_paired = true;
> +
> xudma_tchanrt_write(tx_chn->udma_tchanx, UDMA_CHAN_RT_PEER_RT_EN_REG,
> UDMA_PEER_RT_EN_ENABLE);
>
> @@ -398,6 +397,13 @@ void k3_udma_glue_disable_tx_chn(struct
> k3_udma_glue_tx_channel *tx_chn)
> xudma_tchanrt_write(tx_chn->udma_tchanx,
> UDMA_CHAN_RT_PEER_RT_EN_REG, 0);
> k3_udma_glue_dump_tx_rt_chn(tx_chn, "txchn dis2");
> +
> + if (tx_chn->psil_paired) {
> + xudma_navss_psil_unpair(tx_chn->common.udmax,
> + tx_chn->common.src_thread,
> + tx_chn->common.dst_thread);
> + tx_chn->psil_paired = false;
> + }
> }
> EXPORT_SYMBOL_GPL(k3_udma_glue_disable_tx_chn);
>
> @@ -815,19 +821,6 @@ k3_udma_glue_request_rx_chn_priv(struct device *dev,
> const char *name,
> goto err;
> }
>
> - ret = xudma_navss_psil_pair(rx_chn->common.udmax,
> - rx_chn->common.src_thread,
> - rx_chn->common.dst_thread);
> - if (ret) {
> - dev_err(dev, "PSI-L request err %d\n", ret);
> - goto err;
> - }
> -
> - rx_chn->psil_paired = true;
> -
> - /* reset RX RT registers */
> - k3_udma_glue_disable_rx_chn(rx_chn);
> -
> k3_udma_glue_dump_rx_chn(rx_chn);
>
> return rx_chn;
> @@ -1052,12 +1045,24 @@ EXPORT_SYMBOL_GPL(k3_udma_glue_rx_flow_disable);
>
> int k3_udma_glue_enable_rx_chn(struct k3_udma_glue_rx_channel *rx_chn)
> {
> + int ret;
> +
> if (rx_chn->remote)
> return -EINVAL;
>
> if (rx_chn->flows_ready < rx_chn->flow_num)
> return -EINVAL;
>
> + ret = xudma_navss_psil_pair(rx_chn->common.udmax,
> + rx_chn->common.src_thread,
> + rx_chn->common.dst_thread);
> + if (ret) {
> + dev_err(rx_chn->common.dev, "PSI-L request err %d\n", ret);
> + return ret;
> + }
> +
> + rx_chn->psil_paired = true;
> +
> xudma_rchanrt_write(rx_chn->udma_rchanx, UDMA_CHAN_RT_CTL_REG,
> UDMA_CHAN_RT_CTL_EN);
>
> @@ -1078,6 +1083,13 @@ void k3_udma_glue_disable_rx_chn(struct
> k3_udma_glue_rx_channel *rx_chn)
> xudma_rchanrt_write(rx_chn->udma_rchanx, UDMA_CHAN_RT_CTL_REG, 0)
[tip: irq/urgent] dt-bindings: irqchip: ti, sci-inta: Update for unmapped event handling
The following commit has been merged into the irq/urgent branch of tip: Commit-ID: bb2bd7c7f3d0946acc2104db31df228d10f7b598 Gitweb: https://git.kernel.org/tip/bb2bd7c7f3d0946acc2104db31df228d10f7b598 Author:Peter Ujfalusi AuthorDate:Tue, 20 Oct 2020 10:32:42 +03:00 Committer: Marc Zyngier CommitterDate: Sun, 01 Nov 2020 12:00:50 dt-bindings: irqchip: ti, sci-inta: Update for unmapped event handling The new DMA architecture introduced with AM64 introduced new event types: unampped events. These events are mapped within INTA in contrast to other K3 devices where the events with similar function was originating from the UDMAP or ringacc. The ti,unmapped-event-sources should contain phandle array to the devices in the system (typically DMA controllers) from where the unmapped events originate. Signed-off-by: Peter Ujfalusi Signed-off-by: Marc Zyngier Reviewed-by: Rob Herring Link: https://lore.kernel.org/r/20201020073243.19255-2-peter.ujfal...@ti.com --- Documentation/devicetree/bindings/interrupt-controller/ti,sci-inta.yaml | 10 ++ 1 file changed, 10 insertions(+) diff --git a/Documentation/devicetree/bindings/interrupt-controller/ti,sci-inta.yaml b/Documentation/devicetree/bindings/interrupt-controller/ti,sci-inta.yaml index c7cd056..cc79549 100644 --- a/Documentation/devicetree/bindings/interrupt-controller/ti,sci-inta.yaml +++ b/Documentation/devicetree/bindings/interrupt-controller/ti,sci-inta.yaml @@ -32,6 +32,11 @@ description: | | | vint | bit | | 0 |.|63| vintx | | +--+ ++| | | + | Unmap | + | +--+| + Unmapped events ->| | umapidx|-> Globalevents + | +--+| + | | +-+ Configuration of these Intmap registers that maps global events to vint is @@ -70,6 +75,11 @@ properties: - description: | "limit" specifies the limit for translation + ti,unmapped-event-sources: +$ref: /schemas/types.yaml#definitions/phandle-array +description: + Array of phandles to DMA controllers where the unmapped events originate. + required: - compatible - reg
[tip: irq/urgent] irqchip/ti-sci-inta: Add support for unmapped event handling
The following commit has been merged into the irq/urgent branch of tip:
Commit-ID: d95bdca75b3fb41bf185efe164e05aed820081a5
Gitweb:
https://git.kernel.org/tip/d95bdca75b3fb41bf185efe164e05aed820081a5
Author:Peter Ujfalusi
AuthorDate:Tue, 20 Oct 2020 10:32:43 +03:00
Committer: Marc Zyngier
CommitterDate: Sun, 01 Nov 2020 12:00:50
irqchip/ti-sci-inta: Add support for unmapped event handling
The DMA (BCDMA/PKTDMA and their rings/flows) events are under the INTA's
supervision as unmapped events in AM64.
In order to keep the current SW stack working, the INTA driver must replace
the dev_id with it's own when a request comes for BCDMA or PKTDMA
resources.
Implement parsing of the optional "ti,unmapped-event-sources" phandle array
to get the sci-dev-ids of the devices where the unmapped events originate.
Signed-off-by: Peter Ujfalusi
Signed-off-by: Marc Zyngier
Link: https://lore.kernel.org/r/20201020073243.19255-3-peter.ujfal...@ti.com
---
drivers/irqchip/irq-ti-sci-inta.c | 83 --
1 file changed, 80 insertions(+), 3 deletions(-)
diff --git a/drivers/irqchip/irq-ti-sci-inta.c
b/drivers/irqchip/irq-ti-sci-inta.c
index e0cceb8..b2ab8db 100644
--- a/drivers/irqchip/irq-ti-sci-inta.c
+++ b/drivers/irqchip/irq-ti-sci-inta.c
@@ -85,6 +85,17 @@ struct ti_sci_inta_vint_desc {
* @base: Base address of the memory mapped IO registers
* @pdev: Pointer to platform device.
* @ti_sci_id: TI-SCI device identifier
+ * @unmapped_cnt: Number of @unmapped_dev_ids entries
+ * @unmapped_dev_ids: Pointer to an array of TI-SCI device identifiers of
+ * unmapped event sources.
+ * Unmapped Events are not part of the Global Event Map and
+ * they are converted to Global event within INTA to be
+ * received by the same INTA to generate an interrupt.
+ * In case an interrupt request comes for a device which is
+ * generating Unmapped Event, we must use the INTA's TI-SCI
+ * device identifier in place of the source device
+ * identifier to let sysfw know where it has to program the
+ * Global Event number.
*/
struct ti_sci_inta_irq_domain {
const struct ti_sci_handle *sci;
@@ -96,11 +107,37 @@ struct ti_sci_inta_irq_domain {
void __iomem *base;
struct platform_device *pdev;
u32 ti_sci_id;
+
+ int unmapped_cnt;
+ u16 *unmapped_dev_ids;
};
#define to_vint_desc(e, i) container_of(e, struct ti_sci_inta_vint_desc, \
events[i])
+static u16 ti_sci_inta_get_dev_id(struct ti_sci_inta_irq_domain *inta, u32
hwirq)
+{
+ u16 dev_id = HWIRQ_TO_DEVID(hwirq);
+ int i;
+
+ if (inta->unmapped_cnt == 0)
+ return dev_id;
+
+ /*
+* For devices sending Unmapped Events we must use the INTA's TI-SCI
+* device identifier number to be able to convert it to a Global Event
+* and map it to an interrupt.
+*/
+ for (i = 0; i < inta->unmapped_cnt; i++) {
+ if (dev_id == inta->unmapped_dev_ids[i]) {
+ dev_id = inta->ti_sci_id;
+ break;
+ }
+ }
+
+ return dev_id;
+}
+
/**
* ti_sci_inta_irq_handler() - Chained IRQ handler for the vint irqs
* @desc: Pointer to irq_desc corresponding to the irq
@@ -251,7 +288,7 @@ static struct ti_sci_inta_event_desc
*ti_sci_inta_alloc_event(struct ti_sci_inta
u16 dev_id, dev_index;
int err;
- dev_id = HWIRQ_TO_DEVID(hwirq);
+ dev_id = ti_sci_inta_get_dev_id(inta, hwirq);
dev_index = HWIRQ_TO_IRQID(hwirq);
event_desc = _desc->events[free_bit];
@@ -352,14 +389,15 @@ static void ti_sci_inta_free_irq(struct
ti_sci_inta_event_desc *event_desc,
{
struct ti_sci_inta_vint_desc *vint_desc;
struct ti_sci_inta_irq_domain *inta;
+ u16 dev_id;
vint_desc = to_vint_desc(event_desc, event_desc->vint_bit);
inta = vint_desc->domain->host_data;
+ dev_id = ti_sci_inta_get_dev_id(inta, hwirq);
/* free event irq */
mutex_lock(>vint_mutex);
inta->sci->ops.rm_irq_ops.free_event_map(inta->sci,
-HWIRQ_TO_DEVID(hwirq),
-HWIRQ_TO_IRQID(hwirq),
+dev_id, HWIRQ_TO_IRQID(hwirq),
inta->ti_sci_id,
vint_desc->vint_id,
event_desc->global_event,
@@ -574,6 +612,41 @@ static struct msi_domain_info ti_sci_inta_msi_domain_info
= {
.chip = _sci_inta_msi_ir
[PATCH] thermal: ti-soc-thermal: Disable the CPU PM notifier for OMAP4430
It has been observed that on OMAP4430 (ES2.0, ES2.1 and ES2.3) the enabled
notifier causes errors on the DTEMP readout values:
ti-soc-thermal 4a002260.bandgap: in range ADC val: 52
ti-soc-thermal 4a002260.bandgap: in range ADC val: 64
ti-soc-thermal 4a002260.bandgap: in range ADC val: 64
ti-soc-thermal 4a002260.bandgap: out of range ADC val: 0
thermal thermal_zone0: failed to read out thermal zone (-5)
ti-soc-thermal 4a002260.bandgap: out of range ADC val: 0
thermal thermal_zone0: failed to read out thermal zone (-5)
ti-soc-thermal 4a002260.bandgap: out of range ADC val: 4
thermal thermal_zone0: failed to read out thermal zone (-5)
ti-soc-thermal 4a002260.bandgap: in range ADC val: 100
raw 100 translates to 133 Celsius on omap4-sdp, triggering shutdown due to
critical temperature.
When the notifier is disable for OMAP4430 the DTEMP values are stable:
ti-soc-thermal 4a002260.bandgap: in range ADC val: 56
ti-soc-thermal 4a002260.bandgap: in range ADC val: 56
ti-soc-thermal 4a002260.bandgap: in range ADC val: 57
ti-soc-thermal 4a002260.bandgap: in range ADC val: 57
ti-soc-thermal 4a002260.bandgap: in range ADC val: 56
Fixes: 5093402e5b44 ("thermal: ti-soc-thermal: Enable addition power
management")
Signed-off-by: Peter Ujfalusi
---
Hi,
my omap4-sdp (Blaze) was shutting down randomly due to critical temperature with
5.10-rc1 and I have bisected it back to 5093402e5b44.
Disabling the notifier fixes the random shutdowns on OMAP4430 (ES2.0 and ES2.1)
but it does not cause any issues on OMAP4460 (PandaES) or OMAP3630 (BeagleXM).
Tony's duovero with OMAP4430 ES2.3 did not ninja-shutdown, but he also have
constant and steady stream of:
thermal thermal_zone0: failed to read out thermal zone (-5)
pointing to similar issue.
Regards,
Peter
drivers/thermal/ti-soc-thermal/ti-bandgap.c | 18 --
1 file changed, 16 insertions(+), 2 deletions(-)
diff --git a/drivers/thermal/ti-soc-thermal/ti-bandgap.c
b/drivers/thermal/ti-soc-thermal/ti-bandgap.c
index 5e596168ba73..dcac99f327b0 100644
--- a/drivers/thermal/ti-soc-thermal/ti-bandgap.c
+++ b/drivers/thermal/ti-soc-thermal/ti-bandgap.c
@@ -20,6 +20,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -864,6 +865,17 @@ static struct ti_bandgap *ti_bandgap_build(struct
platform_device *pdev)
return bgp;
}
+/*
+ * List of SoCs on which the CPU PM notifier can cause erros on the DTEMP
+ * readout.
+ * Enabled notifier on these machines results in erroneous, random values which
+ * could trigger unexpected thermal shutdown.
+ */
+static const struct soc_device_attribute soc_no_cpu_notifier[] = {
+ { .machine = "OMAP4430" },
+ { /* sentinel */ },
+};
+
/*** Device driver call backs ***/
static
@@ -1020,7 +1032,8 @@ int ti_bandgap_probe(struct platform_device *pdev)
#ifdef CONFIG_PM_SLEEP
bgp->nb.notifier_call = bandgap_omap_cpu_notifier;
- cpu_pm_register_notifier(>nb);
+ if (!soc_device_match(soc_no_cpu_notifier))
+ cpu_pm_register_notifier(>nb);
#endif
return 0;
@@ -1056,7 +1069,8 @@ int ti_bandgap_remove(struct platform_device *pdev)
struct ti_bandgap *bgp = platform_get_drvdata(pdev);
int i;
- cpu_pm_unregister_notifier(>nb);
+ if (!soc_device_match(soc_no_cpu_notifier))
+ cpu_pm_unregister_notifier(>nb);
/* Remove sensor interfaces */
for (i = 0; i < bgp->conf->sensor_count; i++) {
--
Peter
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
Re: [PATCH 01/18] dmaengine: of-dma: Add support for optional router configuration callback
Hi Vinod, On 28/10/2020 7.55, Vinod Koul wrote: >> To summarize: >> In of_dma_route_allocate() the router does not yet know the channel we >> are going to get. >> In of_dma_xlate() the DMA driver does not yet know if the channel will >> use router or not. >> I need to tell the router the event number it has to send, which is >> based on the channel number I got. > > Sounds reasonable, btw why not pass this information in xlate. Router > will have a different xlate rather than non router right, or is it same. Yes, the router's have their separate xlate, but in that xlate we do not yet have a channel. I don't know what is the event I need to send from the router to trigger the channel. > If this information is anyway available in DT might be better to get it > and use from DT Without a channel number I can not do anything. It is close to a chicken and egg problem. - Péter Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
Re: [PATCH] arm64: dts: ti: k3-j7200-main: Add McASP nodes
On 27/10/2020 15.07, Tony Lindgren wrote: > * Nishanth Menon [201026 14:58]: >> On 13:38-20201007, Peter Ujfalusi wrote: >> [...] >>>>>>> + status = "disabled"; >>>>>> >>>>>> I see that there is inconsistent usage of "disabled" in our SoC.dts >>>>>> >>>>>> Our generic rule has been set them to disabled in board.dtsi >>>>>> McASP and DSS for existing SoC dts do not follow this.. which is a tad >>>>>> confusing.. (considering that not even all uarts come out on every board >>>>>> and every uart needs pinmux to function..) >>>>> >>>>> "keep them disabled because several required properties are not present >>>>> as they are board specific." >>>>> >>>>> In board file the enabled mcasp must be updated with options that is >>>>> required for operation. Without those option the McASP can not be >>>>> initialized. >>>>> >>>>> I think we have been revisiting the very same discussion every time we >>>>> have a new SoC with McASP... >>>>> >>>> >>>> Yep.. This doe'snt really follow the rest of the SoC definition. [1] >>>> came to mind. The McASP discussion is a variation in the debate of the >>>> same. >>> >>> Right, saying status = "okay" to a node which is missing required >>> properties (which can only be added by boards when the McASP is >>> connected up) does not sound a good solution. >>> How should the SW handle that? Fail the device probe and return with >>> -EINVAL or eat up the error and just probe with broken configuration. >>> Since the peripheral is not used, the broken configuration will not >>> cause much runtime errors as there will be no runtime use of the peripheral. >>> >>> status of fail or fail-sss is not a good one either, their definition is: >>> "Indicates that the device is not operational. A serious error was >>> detected in the device, and it is unlikely to become operational without >>> repair." >>> >>> The peripheral is fine, we are just trying to enable it without >>> providing the needed properties. >>> >>>> I'd argue Serdes, or for that matter any IP that has a link to >>>> outside-the-SoC world has the same discussion point. >>> >>> status = "disabled" is still the closest thing for everything which have >>> external dependencies. There is not much point to enable an i2c bus >>> without making sure that the signals are actually routed to the pins >>> where they supposed to go. > > There is one reason to keep using the default status = "okay", for > i2c Linux can properly idle the device on boot without dependencies > to a certain boot loader version. Right, but I would expect board files to disable not used peripherals, peripherals which is not connected up in the board. Including i2c buses. >>> Or from other pow: a board design is not based on what is _not_ >>> connected to outside world, but you actually _connect_ or _enable_ >>> certain peripherals to external components, connectors. >> >> OK, I will buy the argument that the current status thingy is a bit >> overloaded and does'nt imply the correct state we need it to imply with >> "fail-sss" either - I remember an argument for "fail-incomplete", but >> that never happened anyways. >> >> Lets add this argument to the commit message and repost after testing >> on 5.10-rc1 please? > > We should use status = "disabled" when the hardware is not accessible > to the SoC. That goes for things like secure world devices, and hardware > that relies on a missing external clock for example. For other things > we should just stick to the default which "okay" :) Even for peripherals which needs board specific properties and those properties are mandatory for the IP to be operational and usable? The McASP bindings demands several must be present properties (tdm-slots, slot direction for example) and they are coming from the board design. Board files will disable all unused McASPs, they should. Imho the board dts file represents the board design and the board design is to _connect_ peripherals and not _disconnect_ them. Why would a board file should be in charge to disable what is not connected/used? iow: what is the difference of a peripheral disabled in dtsi over a peripheral disabled in board dts file? > > Regards, > > Tony > - Péter Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
Re: [PATCH] dmaengine: ti: k3-udma: fix -Wenum-conversion warning
On 26/10/2020 18.01, Arnd Bergmann wrote:
> From: Arnd Bergmann
>
> gcc warns about a mismatch argument type when passing
> 'false' into a function that expects an enum:
Strange enough, but my gcc does not warn me (Gentoo 10.2.0-r2 p3).
> drivers/dma/ti/k3-udma-private.c: In function 'xudma_tchan_get':
> drivers/dma/ti/k3-udma-private.c:86:34: warning: implicit conversion from
> 'enum ' to 'enum udma_tp_level' [-Wenum-conversion]
> 86 | return __udma_reserve_##res(ud, false, id); \
> | ^
> drivers/dma/ti/k3-udma-private.c:95:1: note: in expansion of macro
> 'XUDMA_GET_PUT_RESOURCE'
>95 | XUDMA_GET_PUT_RESOURCE(tchan);
> | ^~
But this is valid. The Throughput Levels got expanded with j721e from 2
to three and I failed to update this.
> In this case, false has the same numerical value as
> UDMA_TP_NORMAL, so passing that is most likely the correct
> way to avoid the warning without changing the behavior.
Yes, that's correct, thanks for fixing it!
Acked-by: Peter Ujfalusi
> Fixes: d70241913413 ("dmaengine: ti: k3-udma: Add glue layer for non
> DMAengine users")
> Signed-off-by: Arnd Bergmann
> ---
> drivers/dma/ti/k3-udma-private.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/dma/ti/k3-udma-private.c
> b/drivers/dma/ti/k3-udma-private.c
> index aa24e554f7b4..8563a392f30b 100644
> --- a/drivers/dma/ti/k3-udma-private.c
> +++ b/drivers/dma/ti/k3-udma-private.c
> @@ -83,7 +83,7 @@ EXPORT_SYMBOL(xudma_rflow_is_gp);
> #define XUDMA_GET_PUT_RESOURCE(res) \
> struct udma_##res *xudma_##res##_get(struct udma_dev *ud, int id)\
> {\
> - return __udma_reserve_##res(ud, false, id); \
> + return __udma_reserve_##res(ud, UDMA_TP_NORMAL, id);\
> }\
> EXPORT_SYMBOL(xudma_##res##_get);\
> \
>
- Péter
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
