linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
* [PATCH 0/5] dmaengine: ti: edma: Multicore usage related fixes
@ 2019-08-23 12:56 Peter Ujfalusi
  2019-08-23 12:56 ` [PATCH 1/5] dmaengine: ti: edma: Do not reset reserved paRAM slots Peter Ujfalusi
                   ` (5 more replies)
  0 siblings, 6 replies; 11+ messages in thread
From: Peter Ujfalusi @ 2019-08-23 12:56 UTC (permalink / raw)
  To: vkoul, robh+dt
  Cc: devicetree, linux-kernel, dmaengine, dan.j.williams, linux-omap,
	linux-arm-kernel

Hi,

When other cores want to use EDMA for their use cases Linux was not playing
nicely.
By design EDMA is supporting shared use with shadow regions. Linux is using
region0, others can be used by other cores.

In order to not break multicore shared usage of EDMA:
- do not reset paRAM slots which is not allocated for Linux (reserved paRAM
  slots)
- Only reset region0 access registers, do not touch other regions
- Add option for reserved channels which should not be used by Linux in a similar
  fashion as we already have for reserved paRAM slots.

Regards,
Peter
---
Peter Ujfalusi (5):
  dmaengine: ti: edma: Do not reset reserved paRAM slots
  dmaengine: ti: edma: Only reset region0 access registers
  dmaengine: ti: edma: Use bitmap_set() instead of open coded
    edma_set_bits()
  dt-bindings: dma: ti-edma: Add option for reserved channel ranges
  dmaengine: ti: edma: Add support for handling reserved channels

 .../devicetree/bindings/dma/ti-edma.txt       |   5 +
 drivers/dma/ti/edma.c                         | 190 +++++++++++-------
 2 files changed, 123 insertions(+), 72 deletions(-)

-- 
Peter

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


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

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

* [PATCH 1/5] dmaengine: ti: edma: Do not reset reserved paRAM slots
  2019-08-23 12:56 [PATCH 0/5] dmaengine: ti: edma: Multicore usage related fixes Peter Ujfalusi
@ 2019-08-23 12:56 ` Peter Ujfalusi
  2019-08-23 12:56 ` [PATCH 2/5] dmaengine: ti: edma: Only reset region0 access registers Peter Ujfalusi
                   ` (4 subsequent siblings)
  5 siblings, 0 replies; 11+ messages in thread
From: Peter Ujfalusi @ 2019-08-23 12:56 UTC (permalink / raw)
  To: vkoul, robh+dt
  Cc: devicetree, linux-kernel, dmaengine, dan.j.williams, linux-omap,
	linux-arm-kernel

Skip resetting paRAM slots marked as reserved as they might be used by
other cores.

Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
---
 drivers/dma/ti/edma.c | 9 ++++++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/drivers/dma/ti/edma.c b/drivers/dma/ti/edma.c
index 54895112ba59..1aae95cc0d4b 100644
--- a/drivers/dma/ti/edma.c
+++ b/drivers/dma/ti/edma.c
@@ -2338,9 +2338,6 @@ static int edma_probe(struct platform_device *pdev)
 
 	ecc->default_queue = info->default_queue;
 
-	for (i = 0; i < ecc->num_slots; i++)
-		edma_write_slot(ecc, i, &dummy_paramset);
-
 	if (info->rsv) {
 		/* Set the reserved slots in inuse list */
 		rsv_slots = info->rsv->rsv_slots;
@@ -2353,6 +2350,12 @@ static int edma_probe(struct platform_device *pdev)
 		}
 	}
 
+	for (i = 0; i < ecc->num_slots; i++) {
+		/* Reset only unused - not reserved - paRAM slots */
+		if (!test_bit(i, ecc->slot_inuse))
+			edma_write_slot(ecc, i, &dummy_paramset);
+	}
+
 	/* Clear the xbar mapped channels in unused list */
 	xbar_chans = info->xbar_chans;
 	if (xbar_chans) {
-- 
Peter

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


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

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

* [PATCH 2/5] dmaengine: ti: edma: Only reset region0 access registers
  2019-08-23 12:56 [PATCH 0/5] dmaengine: ti: edma: Multicore usage related fixes Peter Ujfalusi
  2019-08-23 12:56 ` [PATCH 1/5] dmaengine: ti: edma: Do not reset reserved paRAM slots Peter Ujfalusi
@ 2019-08-23 12:56 ` Peter Ujfalusi
  2019-08-23 12:56 ` [PATCH 3/5] dmaengine: ti: edma: Use bitmap_set() instead of open coded edma_set_bits() Peter Ujfalusi
                   ` (3 subsequent siblings)
  5 siblings, 0 replies; 11+ messages in thread
From: Peter Ujfalusi @ 2019-08-23 12:56 UTC (permalink / raw)
  To: vkoul, robh+dt
  Cc: devicetree, linux-kernel, dmaengine, dan.j.williams, linux-omap,
	linux-arm-kernel

Region0 is used by Linux, do not reset other registers controlling access
for other shadow regions.

Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
---
 drivers/dma/ti/edma.c | 9 ++++-----
 1 file changed, 4 insertions(+), 5 deletions(-)

diff --git a/drivers/dma/ti/edma.c b/drivers/dma/ti/edma.c
index 1aae95cc0d4b..87450431f336 100644
--- a/drivers/dma/ti/edma.c
+++ b/drivers/dma/ti/edma.c
@@ -2434,11 +2434,10 @@ static int edma_probe(struct platform_device *pdev)
 		edma_assign_priority_to_queue(ecc, queue_priority_mapping[i][0],
 					      queue_priority_mapping[i][1]);
 
-	for (i = 0; i < ecc->num_region; i++) {
-		edma_write_array2(ecc, EDMA_DRAE, i, 0, 0x0);
-		edma_write_array2(ecc, EDMA_DRAE, i, 1, 0x0);
-		edma_write_array(ecc, EDMA_QRAE, i, 0x0);
-	}
+	edma_write_array2(ecc, EDMA_DRAE, 0, 0, 0x0);
+	edma_write_array2(ecc, EDMA_DRAE, 0, 1, 0x0);
+	edma_write_array(ecc, EDMA_QRAE, 0, 0x0);
+
 	ecc->info = info;
 
 	/* Init the dma device and channels */
-- 
Peter

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


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

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

* [PATCH 3/5] dmaengine: ti: edma: Use bitmap_set() instead of open coded edma_set_bits()
  2019-08-23 12:56 [PATCH 0/5] dmaengine: ti: edma: Multicore usage related fixes Peter Ujfalusi
  2019-08-23 12:56 ` [PATCH 1/5] dmaengine: ti: edma: Do not reset reserved paRAM slots Peter Ujfalusi
  2019-08-23 12:56 ` [PATCH 2/5] dmaengine: ti: edma: Only reset region0 access registers Peter Ujfalusi
@ 2019-08-23 12:56 ` Peter Ujfalusi
  2019-08-23 12:56 ` [PATCH 4/5] dt-bindings: dma: ti-edma: Add option for reserved channel ranges Peter Ujfalusi
                   ` (2 subsequent siblings)
  5 siblings, 0 replies; 11+ messages in thread
From: Peter Ujfalusi @ 2019-08-23 12:56 UTC (permalink / raw)
  To: vkoul, robh+dt
  Cc: devicetree, linux-kernel, dmaengine, dan.j.williams, linux-omap,
	linux-arm-kernel

bitmap_set() is the standard way of setting an area in the bitfield.

Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
---
 drivers/dma/ti/edma.c | 17 +++++------------
 1 file changed, 5 insertions(+), 12 deletions(-)

diff --git a/drivers/dma/ti/edma.c b/drivers/dma/ti/edma.c
index 87450431f336..ba7c4f07fcd6 100644
--- a/drivers/dma/ti/edma.c
+++ b/drivers/dma/ti/edma.c
@@ -15,6 +15,7 @@
 
 #include <linux/dmaengine.h>
 #include <linux/dma-mapping.h>
+#include <linux/bitmap.h>
 #include <linux/err.h>
 #include <linux/init.h>
 #include <linux/interrupt.h>
@@ -423,12 +424,6 @@ static inline void edma_param_or(struct edma_cc *ecc, int offset, int param_no,
 	edma_or(ecc, EDMA_PARM + offset + (param_no << 5), or);
 }
 
-static inline void edma_set_bits(int offset, int len, unsigned long *p)
-{
-	for (; len > 0; len--)
-		set_bit(offset + (len - 1), p);
-}
-
 static void edma_assign_priority_to_queue(struct edma_cc *ecc, int queue_no,
 					  int priority)
 {
@@ -2254,7 +2249,7 @@ static int edma_probe(struct platform_device *pdev)
 {
 	struct edma_soc_info	*info = pdev->dev.platform_data;
 	s8			(*queue_priority_mapping)[2];
-	int			i, off, ln;
+	int			i, off;
 	const s16		(*rsv_slots)[2];
 	const s16		(*xbar_chans)[2];
 	int			irq;
@@ -2342,11 +2337,9 @@ static int edma_probe(struct platform_device *pdev)
 		/* Set the reserved slots in inuse list */
 		rsv_slots = info->rsv->rsv_slots;
 		if (rsv_slots) {
-			for (i = 0; rsv_slots[i][0] != -1; i++) {
-				off = rsv_slots[i][0];
-				ln = rsv_slots[i][1];
-				edma_set_bits(off, ln, ecc->slot_inuse);
-			}
+			for (i = 0; rsv_slots[i][0] != -1; i++)
+				bitmap_set(ecc->slot_inuse, rsv_slots[i][0],
+					   rsv_slots[i][1]);
 		}
 	}
 
-- 
Peter

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


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

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

* [PATCH 4/5] dt-bindings: dma: ti-edma: Add option for reserved channel ranges
  2019-08-23 12:56 [PATCH 0/5] dmaengine: ti: edma: Multicore usage related fixes Peter Ujfalusi
                   ` (2 preceding siblings ...)
  2019-08-23 12:56 ` [PATCH 3/5] dmaengine: ti: edma: Use bitmap_set() instead of open coded edma_set_bits() Peter Ujfalusi
@ 2019-08-23 12:56 ` Peter Ujfalusi
  2019-08-29 22:47   ` Rob Herring
  2019-08-23 12:56 ` [PATCH 5/5] dmaengine: ti: edma: Add support for handling reserved channels Peter Ujfalusi
  2019-09-04  9:49 ` [PATCH 0/5] dmaengine: ti: edma: Multicore usage related fixes Vinod Koul
  5 siblings, 1 reply; 11+ messages in thread
From: Peter Ujfalusi @ 2019-08-23 12:56 UTC (permalink / raw)
  To: vkoul, robh+dt
  Cc: devicetree, linux-kernel, dmaengine, dan.j.williams, linux-omap,
	linux-arm-kernel

Similarly to paRAM slots, channels can be used by other cores.

Add optional property to configure the reserved channel ranges.

Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
---
 Documentation/devicetree/bindings/dma/ti-edma.txt | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/Documentation/devicetree/bindings/dma/ti-edma.txt b/Documentation/devicetree/bindings/dma/ti-edma.txt
index 4bbc94d829c8..1198682ada99 100644
--- a/Documentation/devicetree/bindings/dma/ti-edma.txt
+++ b/Documentation/devicetree/bindings/dma/ti-edma.txt
@@ -42,6 +42,9 @@ Optional properties:
 - ti,edma-reserved-slot-ranges: PaRAM slot ranges which should not be used by
 		the driver, they are allocated to be used by for example the
 		DSP. See example.
+- ti,edma-reserved-chan-ranges: channel ranges which should not be used by
+		the driver, they are allocated to be used by for example the
+		DSP. See example.
 
 ------------------------------------------------------------------------------
 eDMA3 Transfer Controller
@@ -91,6 +94,8 @@ edma: edma@49000000 {
 	ti,edma-memcpy-channels = <20 21>;
 	/* The following PaRAM slots are reserved: 35-44 and 100-109 */
 	ti,edma-reserved-slot-ranges = <35 10>, <100 10>;
+	/* The following channels are reserved: 35-44 */
+	ti,edma-reserved-chan-ranges = <35 10>;
 };
 
 edma_tptc0: tptc@49800000 {
-- 
Peter

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


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

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

* [PATCH 5/5] dmaengine: ti: edma: Add support for handling reserved channels
  2019-08-23 12:56 [PATCH 0/5] dmaengine: ti: edma: Multicore usage related fixes Peter Ujfalusi
                   ` (3 preceding siblings ...)
  2019-08-23 12:56 ` [PATCH 4/5] dt-bindings: dma: ti-edma: Add option for reserved channel ranges Peter Ujfalusi
@ 2019-08-23 12:56 ` Peter Ujfalusi
  2019-09-04  9:49 ` [PATCH 0/5] dmaengine: ti: edma: Multicore usage related fixes Vinod Koul
  5 siblings, 0 replies; 11+ messages in thread
From: Peter Ujfalusi @ 2019-08-23 12:56 UTC (permalink / raw)
  To: vkoul, robh+dt
  Cc: devicetree, linux-kernel, dmaengine, dan.j.williams, linux-omap,
	linux-arm-kernel

Like paRAM slots, channels could be used by other cores and in this case
we need to make sure that the driver do not alter these channels.

Move the reserved slot/channel query from DT to a separate function for
cleaner implementation.

Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
---
 drivers/dma/ti/edma.c | 161 +++++++++++++++++++++++++++---------------
 1 file changed, 106 insertions(+), 55 deletions(-)

diff --git a/drivers/dma/ti/edma.c b/drivers/dma/ti/edma.c
index ba7c4f07fcd6..5201aeebf5c1 100644
--- a/drivers/dma/ti/edma.c
+++ b/drivers/dma/ti/edma.c
@@ -260,6 +260,9 @@ struct edma_cc {
 	 */
 	unsigned long *slot_inuse;
 
+	/* for tracking reserved channels used by DSP */
+	unsigned long *reserved_chans;
+
 	struct dma_device		dma_slave;
 	struct dma_device		*dma_memcpy;
 	struct edma_chan		*slave_chans;
@@ -716,6 +719,12 @@ static int edma_alloc_channel(struct edma_chan *echan,
 	struct edma_cc *ecc = echan->ecc;
 	int channel = EDMA_CHAN_SLOT(echan->ch_num);
 
+	if (test_bit(echan->ch_num, ecc->reserved_chans)) {
+		dev_err(ecc->dev, "Channel%d is reserved, can not be used!\n",
+			echan->ch_num);
+		return -EINVAL;
+	}
+
 	/* ensure access through shadow region 0 */
 	edma_or_array2(ecc, EDMA_DRAE, 0, EDMA_REG_ARRAY_INDEX(channel),
 		       EDMA_CHANNEL_BIT(channel));
@@ -2096,6 +2105,76 @@ static int edma_xbar_event_map(struct device *dev, struct edma_soc_info *pdata,
 	return 0;
 }
 
+static struct edma_rsv_info *edma_get_reserved_ranges_dt(struct device *dev)
+{
+	static const char * const prop_names[] = {
+						"ti,edma-reserved-slot-ranges",
+						"ti,edma-reserved-chan-ranges"
+						};
+	struct edma_rsv_info *rsv_info = NULL;
+	struct property *props[2];
+	int sz[2], i, ret;
+
+	for (i = 0; i < 2; i++)
+		props[i] = of_find_property(dev->of_node, prop_names[i],
+					    &sz[i]);
+
+	if (!props[0] && !props[1])
+		return NULL;
+
+	rsv_info = devm_kzalloc(dev, sizeof(*rsv_info), GFP_KERNEL);
+	if (!rsv_info)
+		return ERR_PTR(-ENOMEM);
+
+	for (i = 0; i < 2; i++) {
+		u32 (*tmp)[2];
+		s16 (*reserved)[2];
+		size_t nelm;
+		int j;
+
+		if (!props[i])
+			continue;
+
+		nelm = sz[i] / sizeof(*tmp);
+		if (!nelm)
+			continue;
+
+		tmp = kcalloc(nelm, sizeof(*tmp), GFP_KERNEL);
+		if (!tmp)
+			return ERR_PTR(-ENOMEM);
+
+		reserved = devm_kcalloc(dev, nelm + 1, sizeof(*reserved),
+					GFP_KERNEL);
+		if (!reserved) {
+			kfree(tmp);
+			return ERR_PTR(-ENOMEM);
+		}
+
+		ret = of_property_read_u32_array(dev->of_node, prop_names[i],
+						 (u32 *)tmp, nelm * 2);
+		if (ret) {
+			kfree(tmp);
+			return ERR_PTR(ret);
+		}
+
+		for (j = 0; j < nelm; j++) {
+			reserved[j][0] = tmp[j][0];
+			reserved[j][1] = tmp[j][1];
+		}
+		reserved[nelm][0] = -1;
+		reserved[nelm][1] = -1;
+
+		if (i == 0)
+			rsv_info->rsv_slots = (const s16 (*)[2])reserved;
+		else if (i == 1)
+			rsv_info->rsv_chans = (const s16 (*)[2])reserved;
+
+		kfree(tmp);
+	}
+
+	return rsv_info;
+}
+
 static struct edma_soc_info *edma_setup_info_from_dt(struct device *dev,
 						     bool legacy_mode)
 {
@@ -2139,55 +2218,9 @@ static struct edma_soc_info *edma_setup_info_from_dt(struct device *dev,
 		info->memcpy_channels = memcpy_ch;
 	}
 
-	prop = of_find_property(dev->of_node, "ti,edma-reserved-slot-ranges",
-				&sz);
-	if (prop) {
-		const char pname[] = "ti,edma-reserved-slot-ranges";
-		u32 (*tmp)[2];
-		s16 (*rsv_slots)[2];
-		size_t nelm = sz / sizeof(*tmp);
-		struct edma_rsv_info *rsv_info;
-		int i;
-
-		if (!nelm)
-			return info;
-
-		tmp = kcalloc(nelm, sizeof(*tmp), GFP_KERNEL);
-		if (!tmp)
-			return ERR_PTR(-ENOMEM);
-
-		rsv_info = devm_kzalloc(dev, sizeof(*rsv_info), GFP_KERNEL);
-		if (!rsv_info) {
-			kfree(tmp);
-			return ERR_PTR(-ENOMEM);
-		}
-
-		rsv_slots = devm_kcalloc(dev, nelm + 1, sizeof(*rsv_slots),
-					 GFP_KERNEL);
-		if (!rsv_slots) {
-			kfree(tmp);
-			return ERR_PTR(-ENOMEM);
-		}
-
-		ret = of_property_read_u32_array(dev->of_node, pname,
-						 (u32 *)tmp, nelm * 2);
-		if (ret) {
-			kfree(tmp);
-			return ERR_PTR(ret);
-		}
-
-		for (i = 0; i < nelm; i++) {
-			rsv_slots[i][0] = tmp[i][0];
-			rsv_slots[i][1] = tmp[i][1];
-		}
-		rsv_slots[nelm][0] = -1;
-		rsv_slots[nelm][1] = -1;
-
-		info->rsv = rsv_info;
-		info->rsv->rsv_slots = (const s16 (*)[2])rsv_slots;
-
-		kfree(tmp);
-	}
+	info->rsv = edma_get_reserved_ranges_dt(dev);
+	if (IS_ERR(info->rsv))
+		return ERR_CAST(info->rsv);
 
 	return info;
 }
@@ -2250,7 +2283,7 @@ static int edma_probe(struct platform_device *pdev)
 	struct edma_soc_info	*info = pdev->dev.platform_data;
 	s8			(*queue_priority_mapping)[2];
 	int			i, off;
-	const s16		(*rsv_slots)[2];
+	const s16		(*reserved)[2];
 	const s16		(*xbar_chans)[2];
 	int			irq;
 	char			*irq_name;
@@ -2331,15 +2364,29 @@ static int edma_probe(struct platform_device *pdev)
 	if (!ecc->slot_inuse)
 		return -ENOMEM;
 
+	ecc->reserved_chans = devm_kcalloc(dev,
+					   BITS_TO_LONGS(ecc->num_channels),
+					   sizeof(unsigned long), GFP_KERNEL);
+	if (!ecc->reserved_chans)
+		return -ENOMEM;
+
 	ecc->default_queue = info->default_queue;
 
 	if (info->rsv) {
 		/* Set the reserved slots in inuse list */
-		rsv_slots = info->rsv->rsv_slots;
-		if (rsv_slots) {
-			for (i = 0; rsv_slots[i][0] != -1; i++)
-				bitmap_set(ecc->slot_inuse, rsv_slots[i][0],
-					   rsv_slots[i][1]);
+		reserved = info->rsv->rsv_slots;
+		if (reserved) {
+			for (i = 0; reserved[i][0] != -1; i++)
+				bitmap_set(ecc->slot_inuse, reserved[i][0],
+					   reserved[i][1]);
+		}
+
+		/* Mark reserved channels */
+		reserved = info->rsv->rsv_chans;
+		if (reserved) {
+			for (i = 0; reserved[i][0] != -1; i++)
+				bitmap_set(ecc->reserved_chans, reserved[i][0],
+					   reserved[i][1]);
 		}
 	}
 
@@ -2437,6 +2484,10 @@ static int edma_probe(struct platform_device *pdev)
 	edma_dma_init(ecc, legacy_mode);
 
 	for (i = 0; i < ecc->num_channels; i++) {
+		/* Do not touch reserved channels */
+		if (test_bit(i, ecc->reserved_chans))
+			continue;
+
 		/* Assign all channels to the default queue */
 		edma_assign_channel_eventq(&ecc->slave_chans[i],
 					   info->default_queue);
-- 
Peter

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


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

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

* Re: [PATCH 4/5] dt-bindings: dma: ti-edma: Add option for reserved channel ranges
  2019-08-23 12:56 ` [PATCH 4/5] dt-bindings: dma: ti-edma: Add option for reserved channel ranges Peter Ujfalusi
@ 2019-08-29 22:47   ` Rob Herring
  2019-08-30  5:37     ` Peter Ujfalusi
  0 siblings, 1 reply; 11+ messages in thread
From: Rob Herring @ 2019-08-29 22:47 UTC (permalink / raw)
  To: Peter Ujfalusi
  Cc: devicetree, linux-kernel, vkoul, dmaengine, dan.j.williams,
	linux-omap, linux-arm-kernel

On Fri, Aug 23, 2019 at 03:56:17PM +0300, Peter Ujfalusi wrote:
> Similarly to paRAM slots, channels can be used by other cores.
> 
> Add optional property to configure the reserved channel ranges.
> 
> Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
> ---
>  Documentation/devicetree/bindings/dma/ti-edma.txt | 5 +++++
>  1 file changed, 5 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/dma/ti-edma.txt b/Documentation/devicetree/bindings/dma/ti-edma.txt
> index 4bbc94d829c8..1198682ada99 100644
> --- a/Documentation/devicetree/bindings/dma/ti-edma.txt
> +++ b/Documentation/devicetree/bindings/dma/ti-edma.txt
> @@ -42,6 +42,9 @@ Optional properties:
>  - ti,edma-reserved-slot-ranges: PaRAM slot ranges which should not be used by
>  		the driver, they are allocated to be used by for example the
>  		DSP. See example.
> +- ti,edma-reserved-chan-ranges: channel ranges which should not be used by
> +		the driver, they are allocated to be used by for example the
> +		DSP. See example.

Based on the other thread, I think extending dma-channel-mask to a 
uint32-array makes sense here.

Rob

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

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

* Re: [PATCH 4/5] dt-bindings: dma: ti-edma: Add option for reserved channel ranges
  2019-08-29 22:47   ` Rob Herring
@ 2019-08-30  5:37     ` Peter Ujfalusi
  2019-09-03 10:19       ` Peter Ujfalusi
  0 siblings, 1 reply; 11+ messages in thread
From: Peter Ujfalusi @ 2019-08-30  5:37 UTC (permalink / raw)
  To: Rob Herring
  Cc: devicetree, linux-kernel, vkoul, dmaengine, dan.j.williams,
	linux-omap, linux-arm-kernel

Rob,

On 30/08/2019 1.47, Rob Herring wrote:
> On Fri, Aug 23, 2019 at 03:56:17PM +0300, Peter Ujfalusi wrote:
>> Similarly to paRAM slots, channels can be used by other cores.
>>
>> Add optional property to configure the reserved channel ranges.
>>
>> Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
>> ---
>>  Documentation/devicetree/bindings/dma/ti-edma.txt | 5 +++++
>>  1 file changed, 5 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/dma/ti-edma.txt b/Documentation/devicetree/bindings/dma/ti-edma.txt
>> index 4bbc94d829c8..1198682ada99 100644
>> --- a/Documentation/devicetree/bindings/dma/ti-edma.txt
>> +++ b/Documentation/devicetree/bindings/dma/ti-edma.txt
>> @@ -42,6 +42,9 @@ Optional properties:
>>  - ti,edma-reserved-slot-ranges: PaRAM slot ranges which should not be used by
>>  		the driver, they are allocated to be used by for example the
>>  		DSP. See example.
>> +- ti,edma-reserved-chan-ranges: channel ranges which should not be used by
>> +		the driver, they are allocated to be used by for example the
>> +		DSP. See example.
> 
> Based on the other thread, I think extending dma-channel-mask to a 
> uint32-array makes sense here.

Yes, that is the reason I have asked on that and I'm in progress of
converting the edma driver to use the dma-channel-mask.
Just need to do some shuffling in the driver to get the mask in a form
usable by the driver.

I'll send an updated series early next week.

- Péter

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

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

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

* Re: [PATCH 4/5] dt-bindings: dma: ti-edma: Add option for reserved channel ranges
  2019-08-30  5:37     ` Peter Ujfalusi
@ 2019-09-03 10:19       ` Peter Ujfalusi
  2019-09-06 13:10         ` Rob Herring
  0 siblings, 1 reply; 11+ messages in thread
From: Peter Ujfalusi @ 2019-09-03 10:19 UTC (permalink / raw)
  To: Rob Herring
  Cc: devicetree, linux-kernel, vkoul, dmaengine, dan.j.williams,
	linux-omap, linux-arm-kernel

Hi Rob,

On 30/08/2019 8.37, Peter Ujfalusi wrote:
> Rob,
> 
> On 30/08/2019 1.47, Rob Herring wrote:
>> On Fri, Aug 23, 2019 at 03:56:17PM +0300, Peter Ujfalusi wrote:
>>> Similarly to paRAM slots, channels can be used by other cores.
>>>
>>> Add optional property to configure the reserved channel ranges.
>>>
>>> Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
>>> ---
>>>  Documentation/devicetree/bindings/dma/ti-edma.txt | 5 +++++
>>>  1 file changed, 5 insertions(+)
>>>
>>> diff --git a/Documentation/devicetree/bindings/dma/ti-edma.txt b/Documentation/devicetree/bindings/dma/ti-edma.txt
>>> index 4bbc94d829c8..1198682ada99 100644
>>> --- a/Documentation/devicetree/bindings/dma/ti-edma.txt
>>> +++ b/Documentation/devicetree/bindings/dma/ti-edma.txt
>>> @@ -42,6 +42,9 @@ Optional properties:
>>>  - ti,edma-reserved-slot-ranges: PaRAM slot ranges which should not be used by
>>>  		the driver, they are allocated to be used by for example the
>>>  		DSP. See example.
>>> +- ti,edma-reserved-chan-ranges: channel ranges which should not be used by
>>> +		the driver, they are allocated to be used by for example the
>>> +		DSP. See example.
>>
>> Based on the other thread, I think extending dma-channel-mask to a 
>> uint32-array makes sense here.
> 
> Yes, that is the reason I have asked on that and I'm in progress of
> converting the edma driver to use the dma-channel-mask.
> Just need to do some shuffling in the driver to get the mask in a form
> usable by the driver.
> 
> I'll send an updated series early next week.

How should the dma-channel-mask uint31-array should be documented and used?

Basically some EDMA have 32, some 64 channels. This is fine.
Let's say I want to mask out channel 0-4 and 24-27

This would look like in case of EDMA with 32 channels:
&edma {
	/* channel 0-4 and 24-27 is not to be used */
	dma-channel-mask = <0xf0fffff0>;
};

How this should look like in case when I have 64 channels?
&edma {
	/* channel 0-4 and 24-27 is not to be used */
	dma-channel-mask = <0xf0fffff0>, <0xffffffff>;
};

When I read the u32s then
chan_mask[0] is for channel 0-31 (LSB is channel 0)
chan_maks[1] is for channel 32-63 (LSB is channel 32)

Or:
&edma {
	/* channel 0-4 and 24-27 is not to be used */
	dma-channel-mask = <0xffffffff>, <0xf0fffff0>;
};

chan_maks[0] is for channel 32-63 (LSB is channel 32)
chan_mask[1] is for channel 0-31 (LSB is channel 0)

Do you have pointer on already established notion on how to document and
handle this?

- Péter

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

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

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

* Re: [PATCH 0/5] dmaengine: ti: edma: Multicore usage related fixes
  2019-08-23 12:56 [PATCH 0/5] dmaengine: ti: edma: Multicore usage related fixes Peter Ujfalusi
                   ` (4 preceding siblings ...)
  2019-08-23 12:56 ` [PATCH 5/5] dmaengine: ti: edma: Add support for handling reserved channels Peter Ujfalusi
@ 2019-09-04  9:49 ` Vinod Koul
  5 siblings, 0 replies; 11+ messages in thread
From: Vinod Koul @ 2019-09-04  9:49 UTC (permalink / raw)
  To: Peter Ujfalusi
  Cc: devicetree, linux-kernel, robh+dt, dmaengine, dan.j.williams,
	linux-omap, linux-arm-kernel

On 23-08-19, 15:56, Peter Ujfalusi wrote:
> Hi,
> 
> When other cores want to use EDMA for their use cases Linux was not playing
> nicely.
> By design EDMA is supporting shared use with shadow regions. Linux is using
> region0, others can be used by other cores.
> 
> In order to not break multicore shared usage of EDMA:
> - do not reset paRAM slots which is not allocated for Linux (reserved paRAM
>   slots)
> - Only reset region0 access registers, do not touch other regions
> - Add option for reserved channels which should not be used by Linux in a similar
>   fashion as we already have for reserved paRAM slots.

Applied 1 to 3, thanks

-- 
~Vinod

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

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

* Re: [PATCH 4/5] dt-bindings: dma: ti-edma: Add option for reserved channel ranges
  2019-09-03 10:19       ` Peter Ujfalusi
@ 2019-09-06 13:10         ` Rob Herring
  0 siblings, 0 replies; 11+ messages in thread
From: Rob Herring @ 2019-09-06 13:10 UTC (permalink / raw)
  To: Peter Ujfalusi
  Cc: devicetree, linux-kernel, Vinod,
	open list:DMA GENERIC OFFLOAD ENGINE SUBSYSTEM, Dan Williams,
	linux-omap,
	moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE

On Tue, Sep 3, 2019 at 11:19 AM Peter Ujfalusi <peter.ujfalusi@ti.com> wrote:
>
> Hi Rob,
>
> On 30/08/2019 8.37, Peter Ujfalusi wrote:
> > Rob,
> >
> > On 30/08/2019 1.47, Rob Herring wrote:
> >> On Fri, Aug 23, 2019 at 03:56:17PM +0300, Peter Ujfalusi wrote:
> >>> Similarly to paRAM slots, channels can be used by other cores.
> >>>
> >>> Add optional property to configure the reserved channel ranges.
> >>>
> >>> Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
> >>> ---
> >>>  Documentation/devicetree/bindings/dma/ti-edma.txt | 5 +++++
> >>>  1 file changed, 5 insertions(+)
> >>>
> >>> diff --git a/Documentation/devicetree/bindings/dma/ti-edma.txt b/Documentation/devicetree/bindings/dma/ti-edma.txt
> >>> index 4bbc94d829c8..1198682ada99 100644
> >>> --- a/Documentation/devicetree/bindings/dma/ti-edma.txt
> >>> +++ b/Documentation/devicetree/bindings/dma/ti-edma.txt
> >>> @@ -42,6 +42,9 @@ Optional properties:
> >>>  - ti,edma-reserved-slot-ranges: PaRAM slot ranges which should not be used by
> >>>             the driver, they are allocated to be used by for example the
> >>>             DSP. See example.
> >>> +- ti,edma-reserved-chan-ranges: channel ranges which should not be used by
> >>> +           the driver, they are allocated to be used by for example the
> >>> +           DSP. See example.
> >>
> >> Based on the other thread, I think extending dma-channel-mask to a
> >> uint32-array makes sense here.
> >
> > Yes, that is the reason I have asked on that and I'm in progress of
> > converting the edma driver to use the dma-channel-mask.
> > Just need to do some shuffling in the driver to get the mask in a form
> > usable by the driver.
> >
> > I'll send an updated series early next week.
>
> How should the dma-channel-mask uint31-array should be documented and used?
>
> Basically some EDMA have 32, some 64 channels. This is fine.
> Let's say I want to mask out channel 0-4 and 24-27
>
> This would look like in case of EDMA with 32 channels:
> &edma {
>         /* channel 0-4 and 24-27 is not to be used */
>         dma-channel-mask = <0xf0fffff0>;
> };
>
> How this should look like in case when I have 64 channels?
> &edma {
>         /* channel 0-4 and 24-27 is not to be used */
>         dma-channel-mask = <0xf0fffff0>, <0xffffffff>;
> };
>
> When I read the u32s then
> chan_mask[0] is for channel 0-31 (LSB is channel 0)
> chan_maks[1] is for channel 32-63 (LSB is channel 32)
>
> Or:
> &edma {
>         /* channel 0-4 and 24-27 is not to be used */
>         dma-channel-mask = <0xffffffff>, <0xf0fffff0>;
> };
>
> chan_maks[0] is for channel 32-63 (LSB is channel 32)
> chan_mask[1] is for channel 0-31 (LSB is channel 0)
>
> Do you have pointer on already established notion on how to document and
> handle this?

As far as word ordering, I guess you can do whatever order you want.
MSB first would make the most sense if this was only going to be up to
64-bit. But given it could be 96, 128, ... bits, probably the least
significant word first makes sense and is easier to parse for a
variable length.

The binding schema can be something like this:

items:
  - description: Mask of channels 0-31
  - description: Mask of channels 32-63

The length is implied by the number of list items.

Rob

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

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

end of thread, other threads:[~2019-09-06 13:10 UTC | newest]

Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-08-23 12:56 [PATCH 0/5] dmaengine: ti: edma: Multicore usage related fixes Peter Ujfalusi
2019-08-23 12:56 ` [PATCH 1/5] dmaengine: ti: edma: Do not reset reserved paRAM slots Peter Ujfalusi
2019-08-23 12:56 ` [PATCH 2/5] dmaengine: ti: edma: Only reset region0 access registers Peter Ujfalusi
2019-08-23 12:56 ` [PATCH 3/5] dmaengine: ti: edma: Use bitmap_set() instead of open coded edma_set_bits() Peter Ujfalusi
2019-08-23 12:56 ` [PATCH 4/5] dt-bindings: dma: ti-edma: Add option for reserved channel ranges Peter Ujfalusi
2019-08-29 22:47   ` Rob Herring
2019-08-30  5:37     ` Peter Ujfalusi
2019-09-03 10:19       ` Peter Ujfalusi
2019-09-06 13:10         ` Rob Herring
2019-08-23 12:56 ` [PATCH 5/5] dmaengine: ti: edma: Add support for handling reserved channels Peter Ujfalusi
2019-09-04  9:49 ` [PATCH 0/5] dmaengine: ti: edma: Multicore usage related fixes 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).