linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH] dmaengine: ti: k3-udma-glue: move psi-l pairing in channel en/dis functions
@ 2020-10-30 20:30 Grygorii Strashko
  2020-11-02  7:46 ` Peter Ujfalusi
  2020-11-09 11:54 ` Vinod Koul
  0 siblings, 2 replies; 4+ messages in thread
From: Grygorii Strashko @ 2020-10-30 20:30 UTC (permalink / raw)
  To: Vinod Koul, Peter Ujfalusi, dmaengine
  Cc: Sekhar Nori, linux-kernel, Vignesh Raghavendra, Grygorii Strashko

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.

Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
---
 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);
 
 	k3_udma_glue_dump_rx_rt_chn(rx_chn, "rxrt dis2");
+
+	if (rx_chn->psil_paired) {
+		xudma_navss_psil_unpair(rx_chn->common.udmax,
+					rx_chn->common.src_thread,
+					rx_chn->common.dst_thread);
+		rx_chn->psil_paired = false;
+	}
 }
 EXPORT_SYMBOL_GPL(k3_udma_glue_disable_rx_chn);
 
-- 
2.17.1


^ permalink raw reply related	[flat|nested] 4+ messages in thread

* Re: [PATCH] dmaengine: ti: k3-udma-glue: move psi-l pairing in channel en/dis functions
  2020-10-30 20:30 [PATCH] dmaengine: ti: k3-udma-glue: move psi-l pairing in channel en/dis functions Grygorii Strashko
@ 2020-11-02  7:46 ` Peter Ujfalusi
  2020-11-04 11:32   ` Grygorii Strashko
  2020-11-09 11:54 ` Vinod Koul
  1 sibling, 1 reply; 4+ messages in thread
From: Peter Ujfalusi @ 2020-11-02  7:46 UTC (permalink / raw)
  To: Grygorii Strashko, Vinod Koul, dmaengine
  Cc: Sekhar Nori, linux-kernel, Vignesh Raghavendra



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 <peter.ujfalusi@ti.com>


> Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
> ---
>  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);
>  
>  	k3_udma_glue_dump_rx_rt_chn(rx_chn, "rxrt dis2");
> +
> +	if (rx_chn->psil_paired) {
> +		xudma_navss_psil_unpair(rx_chn->common.udmax,
> +					rx_chn->common.src_thread,
> +					rx_chn->common.dst_thread);
> +		rx_chn->psil_paired = false;
> +	}
>  }
>  EXPORT_SYMBOL_GPL(k3_udma_glue_disable_rx_chn);
>  
> 

- Péter

Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH] dmaengine: ti: k3-udma-glue: move psi-l pairing in channel en/dis functions
  2020-11-02  7:46 ` Peter Ujfalusi
@ 2020-11-04 11:32   ` Grygorii Strashko
  0 siblings, 0 replies; 4+ messages in thread
From: Grygorii Strashko @ 2020-11-04 11:32 UTC (permalink / raw)
  To: Peter Ujfalusi, Vinod Koul, dmaengine
  Cc: Sekhar Nori, linux-kernel, Vignesh Raghavendra



On 02/11/2020 09:46, Peter Ujfalusi wrote:
> 
> 
> 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?

No. It was not based on top of AM64 series and I've not checked for conflicts.

> 
> Acked-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
> 
> 
>> Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
>> ---
>>   drivers/dma/ti/k3-udma-glue.c | 64 +++++++++++++++++++++--------------
>>   1 file changed, 38 insertions(+), 26 deletions(-)

...

-- 
Best regards,
grygorii

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH] dmaengine: ti: k3-udma-glue: move psi-l pairing in channel en/dis functions
  2020-10-30 20:30 [PATCH] dmaengine: ti: k3-udma-glue: move psi-l pairing in channel en/dis functions Grygorii Strashko
  2020-11-02  7:46 ` Peter Ujfalusi
@ 2020-11-09 11:54 ` Vinod Koul
  1 sibling, 0 replies; 4+ messages in thread
From: Vinod Koul @ 2020-11-09 11:54 UTC (permalink / raw)
  To: Grygorii Strashko
  Cc: Peter Ujfalusi, dmaengine, Sekhar Nori, linux-kernel,
	Vignesh Raghavendra

On 30-10-20, 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.

Applied, thanks

-- 
~Vinod

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2020-11-09 11:54 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-10-30 20:30 [PATCH] dmaengine: ti: k3-udma-glue: move psi-l pairing in channel en/dis functions Grygorii Strashko
2020-11-02  7:46 ` Peter Ujfalusi
2020-11-04 11:32   ` Grygorii Strashko
2020-11-09 11:54 ` Vinod Koul

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).