[PATCH v4 01/10] dmaengine: Actions: get rid of bit fields from dma descriptor

[PATCH v4 01/10] dmaengine: Actions: get rid of bit fields from dma descriptor

[Amit Singh Tomar]

At the moment, Driver uses bit fields to describe registers of the DMA
descriptor structure that makes it less portable and maintainable, and
Andre suugested(and even sketched important bits for it) to make use of
array to describe this DMA descriptors instead. It gives the flexibility
while extending support for other platform such as Actions S700.

This commit removes the "owl_dma_lli_hw" (that includes bit-fields) and
uses array to describe DMA descriptor.

Suggested-by: Andre Przywara <andre.przywara@arm.com>
Signed-off-by: Amit Singh Tomar <amittomer25@gmail.com>
---
Changes since v3:
	* Added description for enum fields.
	* Restored the old comment.
	* Added detailed comment about, the way FLEN
	  and FCNT values are filled.
Changes since v2:
	* No change.
Changes since v1:
	* Defined macro for frame count value.
	* Introduced llc_hw_flen() from patch 2/9.
	* Removed the unnecessary line break.
Changes since rfc:
	* No change.
---
 drivers/dma/owl-dma.c | 98 +++++++++++++++++++++++++++++----------------------
 1 file changed, 56 insertions(+), 42 deletions(-)

diff --git a/drivers/dma/owl-dma.c b/drivers/dma/owl-dma.c
index 66ef70b00ec0..948d1bead860 100644
--- a/drivers/dma/owl-dma.c
+++ b/drivers/dma/owl-dma.c
@@ -120,30 +120,33 @@
 #define BIT_FIELD(val, width, shift, newshift)	\
 		((((val) >> (shift)) & ((BIT(width)) - 1)) << (newshift))
 
+/* Frame count value is fixed as 1 */
+#define FCNT_VAL				0x1
+
 /**
- * struct owl_dma_lli_hw - Hardware link list for dma transfer
- * @next_lli: physical address of the next link list
- * @saddr: source physical address
- * @daddr: destination physical address
- * @flen: frame length
- * @fcnt: frame count
- * @src_stride: source stride
- * @dst_stride: destination stride
- * @ctrla: dma_mode and linklist ctrl config
- * @ctrlb: interrupt config
- * @const_num: data for constant fill
+ * owl_dmadesc_offsets - Describe DMA descriptor, hardware link
+ * list for dma transfer
+ * @OWL_DMADESC_NEXT_LLI: physical address of the next link list
+ * @OWL_DMADESC_SADDR: source physical address
+ * @OWL_DMADESC_DADDR: destination physical address
+ * @OWL_DMADESC_FLEN: frame length
+ * @OWL_DMADESC_SRC_STRIDE: source stride
+ * @OWL_DMADESC_DST_STRIDE: destination stride
+ * @OWL_DMADESC_CTRLA: dma_mode and linklist ctrl config
+ * @OWL_DMADESC_CTRLB: interrupt config
+ * @OWL_DMADESC_CONST_NUM: data for constant fill
  */
-struct owl_dma_lli_hw {
-	u32	next_lli;
-	u32	saddr;
-	u32	daddr;
-	u32	flen:20;
-	u32	fcnt:12;
-	u32	src_stride;
-	u32	dst_stride;
-	u32	ctrla;
-	u32	ctrlb;
-	u32	const_num;
+enum owl_dmadesc_offsets {
+	OWL_DMADESC_NEXT_LLI = 0,
+	OWL_DMADESC_SADDR,
+	OWL_DMADESC_DADDR,
+	OWL_DMADESC_FLEN,
+	OWL_DMADESC_SRC_STRIDE,
+	OWL_DMADESC_DST_STRIDE,
+	OWL_DMADESC_CTRLA,
+	OWL_DMADESC_CTRLB,
+	OWL_DMADESC_CONST_NUM,
+	OWL_DMADESC_SIZE
 };
 
 /**
@@ -153,7 +156,7 @@ struct owl_dma_lli_hw {
  * @node: node for txd's lli_list
  */
 struct owl_dma_lli {
-	struct  owl_dma_lli_hw	hw;
+	u32			hw[OWL_DMADESC_SIZE];
 	dma_addr_t		phys;
 	struct list_head	node;
 };
@@ -318,6 +321,11 @@ static inline u32 llc_hw_ctrlb(u32 int_ctl)
 	return ctl;
 }
 
+static u32 llc_hw_flen(struct owl_dma_lli *lli)
+{
+	return lli->hw[OWL_DMADESC_FLEN] & GENMASK(19, 0);
+}
+
 static void owl_dma_free_lli(struct owl_dma *od,
 			     struct owl_dma_lli *lli)
 {
@@ -349,8 +357,9 @@ static struct owl_dma_lli *owl_dma_add_lli(struct owl_dma_txd *txd,
 		list_add_tail(&next->node, &txd->lli_list);
 
 	if (prev) {
-		prev->hw.next_lli = next->phys;
-		prev->hw.ctrla |= llc_hw_ctrla(OWL_DMA_MODE_LME, 0);
+		prev->hw[OWL_DMADESC_NEXT_LLI] = next->phys;
+		prev->hw[OWL_DMADESC_CTRLA] |=
+					llc_hw_ctrla(OWL_DMA_MODE_LME, 0);
 	}
 
 	return next;
@@ -363,8 +372,7 @@ static inline int owl_dma_cfg_lli(struct owl_dma_vchan *vchan,
 				  struct dma_slave_config *sconfig,
 				  bool is_cyclic)
 {
-	struct owl_dma_lli_hw *hw = &lli->hw;
-	u32 mode;
+	u32 mode, ctrlb;
 
 	mode = OWL_DMA_MODE_PW(0);
 
@@ -405,22 +413,28 @@ static inline int owl_dma_cfg_lli(struct owl_dma_vchan *vchan,
 		return -EINVAL;
 	}
 
-	hw->next_lli = 0; /* One link list by default */
-	hw->saddr = src;
-	hw->daddr = dst;
-
-	hw->fcnt = 1; /* Frame count fixed as 1 */
-	hw->flen = len; /* Max frame length is 1MB */
-	hw->src_stride = 0;
-	hw->dst_stride = 0;
-	hw->ctrla = llc_hw_ctrla(mode,
-				 OWL_DMA_LLC_SAV_LOAD_NEXT |
-				 OWL_DMA_LLC_DAV_LOAD_NEXT);
+	lli->hw[OWL_DMADESC_CTRLA] = llc_hw_ctrla(mode,
+						  OWL_DMA_LLC_SAV_LOAD_NEXT |
+						  OWL_DMA_LLC_DAV_LOAD_NEXT);
 
 	if (is_cyclic)
-		hw->ctrlb = llc_hw_ctrlb(OWL_DMA_INTCTL_BLOCK);
+		ctrlb = llc_hw_ctrlb(OWL_DMA_INTCTL_BLOCK);
 	else
-		hw->ctrlb = llc_hw_ctrlb(OWL_DMA_INTCTL_SUPER_BLOCK);
+		ctrlb = llc_hw_ctrlb(OWL_DMA_INTCTL_SUPER_BLOCK);
+
+	lli->hw[OWL_DMADESC_NEXT_LLI] = 0; /* One link list by default */
+	lli->hw[OWL_DMADESC_SADDR] = src;
+	lli->hw[OWL_DMADESC_DADDR] = dst;
+	lli->hw[OWL_DMADESC_SRC_STRIDE] = 0;
+	lli->hw[OWL_DMADESC_DST_STRIDE] = 0;
+	/*
+	 * Word starts from offset 0xC is shared between frame length
+	 * (max frame length is 1MB) and frame count, where first 20
+	 * bits are for frame length and rest of 12 bits are for frame
+	 * count.
+	 */
+	lli->hw[OWL_DMADESC_FLEN] = len | FCNT_VAL << 20;
+	lli->hw[OWL_DMADESC_CTRLB] = ctrlb;
 
 	return 0;
 }
@@ -752,7 +766,7 @@ static u32 owl_dma_getbytes_chan(struct owl_dma_vchan *vchan)
 			/* Start from the next active node */
 			if (lli->phys == next_lli_phy) {
 				list_for_each_entry(lli, &txd->lli_list, node)
-					bytes += lli->hw.flen;
+					bytes += llc_hw_flen(lli);
 				break;
 			}
 		}
@@ -783,7 +797,7 @@ static enum dma_status owl_dma_tx_status(struct dma_chan *chan,
 	if (vd) {
 		txd = to_owl_txd(&vd->tx);
 		list_for_each_entry(lli, &txd->lli_list, node)
-			bytes += lli->hw.flen;
+			bytes += llc_hw_flen(lli);
 	} else {
 		bytes = owl_dma_getbytes_chan(vchan);
 	}
-- 
2.7.4

[PATCH v4 02/10] dmaengine: Actions: Add support for S700 DMA engine

[Amit Singh Tomar]

DMA controller present on S700 SoC is compatible with the one on S900
(as most of registers are same), but it has different DMA descriptor
structure where registers "fcnt" and "ctrlb" uses different encoding.

For instance, on S900 "fcnt" starts at offset 0x0c and uses upper 12
bits whereas on S700, it starts at offset 0x1c and uses lower 12 bits.

This commit adds support for DMA controller present on S700.

Signed-off-by: Amit Singh Tomar <amittomer25@gmail.com>
---
Changes since v3:
	* Provided detailed comment about, the way
	  shared DMA descriptor fields are programmed.
        * Fixed following clang compilation warning:
	  warning: cast to smaller integer type 'enum owl_dma_id' from 'const void *'
	  [-Wvoid-pointer-to-enum-cast]
Changes since v2:
	* No changes.
Changes since v1:
	* Moved llc_hw_flen() to patch 1/9.
	* provided comments about dma descriptor difference.
	  between S700 and S900.
Changes since RFC:
	* Added accessor function to get the frame lenght.
	* Removed the SoC specific check in IRQ routine.
---
 drivers/dma/owl-dma.c | 59 ++++++++++++++++++++++++++++++++++++++-------------
 1 file changed, 44 insertions(+), 15 deletions(-)

diff --git a/drivers/dma/owl-dma.c b/drivers/dma/owl-dma.c
index 948d1bead860..f0c5425c06e7 100644
--- a/drivers/dma/owl-dma.c
+++ b/drivers/dma/owl-dma.c
@@ -149,6 +149,11 @@ enum owl_dmadesc_offsets {
 	OWL_DMADESC_SIZE
 };
 
+enum owl_dma_id {
+	S900_DMA,
+	S700_DMA,
+};
+
 /**
  * struct owl_dma_lli - Link list for dma transfer
  * @hw: hardware link list
@@ -213,6 +218,7 @@ struct owl_dma_vchan {
  * @pchans: array of data for the physical channels
  * @nr_vchans: the number of physical channels
  * @vchans: array of data for the physical channels
+ * @devid: device id based on OWL SoC
  */
 struct owl_dma {
 	struct dma_device	dma;
@@ -227,6 +233,7 @@ struct owl_dma {
 
 	unsigned int		nr_vchans;
 	struct owl_dma_vchan	*vchans;
+	enum owl_dma_id		devid;
 };
 
 static void pchan_update(struct owl_dma_pchan *pchan, u32 reg,
@@ -316,6 +323,10 @@ static inline u32 llc_hw_ctrlb(u32 int_ctl)
 {
 	u32 ctl;
 
+	/*
+	 * Irrespective of the SoC, ctrlb value starts filling from
+	 * bit 18.
+	 */
 	ctl = BIT_FIELD(int_ctl, 7, 0, 18);
 
 	return ctl;
@@ -372,6 +383,7 @@ static inline int owl_dma_cfg_lli(struct owl_dma_vchan *vchan,
 				  struct dma_slave_config *sconfig,
 				  bool is_cyclic)
 {
+	struct owl_dma *od = to_owl_dma(vchan->vc.chan.device);
 	u32 mode, ctrlb;
 
 	mode = OWL_DMA_MODE_PW(0);
@@ -427,14 +439,26 @@ static inline int owl_dma_cfg_lli(struct owl_dma_vchan *vchan,
 	lli->hw[OWL_DMADESC_DADDR] = dst;
 	lli->hw[OWL_DMADESC_SRC_STRIDE] = 0;
 	lli->hw[OWL_DMADESC_DST_STRIDE] = 0;
-	/*
-	 * Word starts from offset 0xC is shared between frame length
-	 * (max frame length is 1MB) and frame count, where first 20
-	 * bits are for frame length and rest of 12 bits are for frame
-	 * count.
-	 */
-	lli->hw[OWL_DMADESC_FLEN] = len | FCNT_VAL << 20;
-	lli->hw[OWL_DMADESC_CTRLB] = ctrlb;
+
+	if (od->devid == S700_DMA) {
+		/* Max frame length is 1MB */
+		lli->hw[OWL_DMADESC_FLEN] = len;
+		/*
+		 * On S700, word starts from offset 0x1C is shared between
+		 * frame count and ctrlb, where first 12 bits are for frame
+		 * count and rest of 20 bits are for ctrlb.
+		 */
+		lli->hw[OWL_DMADESC_CTRLB] = FCNT_VAL | ctrlb;
+	} else {
+		/*
+		 * On S900, word starts from offset 0xC is shared between
+		 * frame length (max frame length is 1MB) and frame count,
+		 * where first 20 bits are for frame length and rest of
+		 * 12 bits are for frame count.
+		 */
+		lli->hw[OWL_DMADESC_FLEN] = len | FCNT_VAL << 20;
+		lli->hw[OWL_DMADESC_CTRLB] = ctrlb;
+	}
 
 	return 0;
 }
@@ -596,7 +620,7 @@ static irqreturn_t owl_dma_interrupt(int irq, void *dev_id)
 
 		global_irq_pending = dma_readl(od, OWL_DMA_IRQ_PD0);
 
-		if (chan_irq_pending && !(global_irq_pending & BIT(i)))	{
+		if (chan_irq_pending && !(global_irq_pending & BIT(i))) {
 			dev_dbg(od->dma.dev,
 				"global and channel IRQ pending match err\n");
 
@@ -1054,11 +1078,20 @@ static struct dma_chan *owl_dma_of_xlate(struct of_phandle_args *dma_spec,
 	return chan;
 }
 
+static const struct of_device_id owl_dma_match[] = {
+	{ .compatible = "actions,s900-dma", .data = (void *)S900_DMA,},
+	{ .compatible = "actions,s700-dma", .data = (void *)S700_DMA,},
+	{ /* sentinel */ },
+};
+MODULE_DEVICE_TABLE(of, owl_dma_match);
+
 static int owl_dma_probe(struct platform_device *pdev)
 {
 	struct device_node *np = pdev->dev.of_node;
 	struct owl_dma *od;
 	int ret, i, nr_channels, nr_requests;
+	const struct of_device_id *of_id =
+				of_match_device(owl_dma_match, &pdev->dev);
 
 	od = devm_kzalloc(&pdev->dev, sizeof(*od), GFP_KERNEL);
 	if (!od)
@@ -1083,6 +1116,8 @@ static int owl_dma_probe(struct platform_device *pdev)
 	dev_info(&pdev->dev, "dma-channels %d, dma-requests %d\n",
 		 nr_channels, nr_requests);
 
+	od->devid = (enum owl_dma_id)(uintptr_t)of_id->data;
+
 	od->nr_pchans = nr_channels;
 	od->nr_vchans = nr_requests;
 
@@ -1215,12 +1250,6 @@ static int owl_dma_remove(struct platform_device *pdev)
 	return 0;
 }
 
-static const struct of_device_id owl_dma_match[] = {
-	{ .compatible = "actions,s900-dma", },
-	{ /* sentinel */ }
-};
-MODULE_DEVICE_TABLE(of, owl_dma_match);
-
 static struct platform_driver owl_dma_driver = {
 	.probe	= owl_dma_probe,
 	.remove	= owl_dma_remove,
-- 
2.7.4

Re: [PATCH v4 02/10] dmaengine: Actions: Add support for S700 DMA engine

[Vinod Koul]

Hi Amit,

On 09-06-20, 15:47, Amit Singh Tomar wrote:

> @@ -372,6 +383,7 @@ static inline int owl_dma_cfg_lli(struct owl_dma_vchan *vchan,
>  				  struct dma_slave_config *sconfig,
>  				  bool is_cyclic)
>  {
> +	struct owl_dma *od = to_owl_dma(vchan->vc.chan.device);
>  	u32 mode, ctrlb;
>  
>  	mode = OWL_DMA_MODE_PW(0);
> @@ -427,14 +439,26 @@ static inline int owl_dma_cfg_lli(struct owl_dma_vchan *vchan,
>  	lli->hw[OWL_DMADESC_DADDR] = dst;
>  	lli->hw[OWL_DMADESC_SRC_STRIDE] = 0;
>  	lli->hw[OWL_DMADESC_DST_STRIDE] = 0;
> -	/*
> -	 * Word starts from offset 0xC is shared between frame length
> -	 * (max frame length is 1MB) and frame count, where first 20
> -	 * bits are for frame length and rest of 12 bits are for frame
> -	 * count.
> -	 */
> -	lli->hw[OWL_DMADESC_FLEN] = len | FCNT_VAL << 20;
> -	lli->hw[OWL_DMADESC_CTRLB] = ctrlb;
> +
> +	if (od->devid == S700_DMA) {
> +		/* Max frame length is 1MB */
> +		lli->hw[OWL_DMADESC_FLEN] = len;
> +		/*
> +		 * On S700, word starts from offset 0x1C is shared between
> +		 * frame count and ctrlb, where first 12 bits are for frame
> +		 * count and rest of 20 bits are for ctrlb.
> +		 */
> +		lli->hw[OWL_DMADESC_CTRLB] = FCNT_VAL | ctrlb;
> +	} else {
> +		/*
> +		 * On S900, word starts from offset 0xC is shared between
> +		 * frame length (max frame length is 1MB) and frame count,
> +		 * where first 20 bits are for frame length and rest of
> +		 * 12 bits are for frame count.
> +		 */
> +		lli->hw[OWL_DMADESC_FLEN] = len | FCNT_VAL << 20;
> +		lli->hw[OWL_DMADESC_CTRLB] = ctrlb;

Unfortunately this wont scale, we will keep adding new conditions for
newer SoC's! So rather than this why not encode max frame length in
driver_data rather than S900_DMA/S700_DMA.. In future one can add values
for newer SoC and not code above logic again.

> +static const struct of_device_id owl_dma_match[] = {
> +	{ .compatible = "actions,s900-dma", .data = (void *)S900_DMA,},
> +	{ .compatible = "actions,s700-dma", .data = (void *)S700_DMA,},

Is the .compatible documented, Documentation patch should come before
the driver use patch in a series

>  static int owl_dma_probe(struct platform_device *pdev)
>  {
>  	struct device_node *np = pdev->dev.of_node;
>  	struct owl_dma *od;
>  	int ret, i, nr_channels, nr_requests;
> +	const struct of_device_id *of_id =
> +				of_match_device(owl_dma_match, &pdev->dev);

You care about driver_data rather than of_id, so using
of_device_get_match_data() would be better..

>  	od = devm_kzalloc(&pdev->dev, sizeof(*od), GFP_KERNEL);
>  	if (!od)
> @@ -1083,6 +1116,8 @@ static int owl_dma_probe(struct platform_device *pdev)
>  	dev_info(&pdev->dev, "dma-channels %d, dma-requests %d\n",
>  		 nr_channels, nr_requests);
>  
> +	od->devid = (enum owl_dma_id)(uintptr_t)of_id->data;

Funny casts, I dont think you need uintptr_t!
-- 
~Vinod

Re: [PATCH v4 02/10] dmaengine: Actions: Add support for S700 DMA engine

[André Przywara]

On 24/06/2020 07:15, Vinod Koul wrote:

Hi,

> On 09-06-20, 15:47, Amit Singh Tomar wrote:
> 
>> @@ -372,6 +383,7 @@ static inline int owl_dma_cfg_lli(struct owl_dma_vchan *vchan,
>>  				  struct dma_slave_config *sconfig,
>>  				  bool is_cyclic)
>>  {
>> +	struct owl_dma *od = to_owl_dma(vchan->vc.chan.device);
>>  	u32 mode, ctrlb;
>>  
>>  	mode = OWL_DMA_MODE_PW(0);
>> @@ -427,14 +439,26 @@ static inline int owl_dma_cfg_lli(struct owl_dma_vchan *vchan,
>>  	lli->hw[OWL_DMADESC_DADDR] = dst;
>>  	lli->hw[OWL_DMADESC_SRC_STRIDE] = 0;
>>  	lli->hw[OWL_DMADESC_DST_STRIDE] = 0;
>> -	/*
>> -	 * Word starts from offset 0xC is shared between frame length
>> -	 * (max frame length is 1MB) and frame count, where first 20
>> -	 * bits are for frame length and rest of 12 bits are for frame
>> -	 * count.
>> -	 */
>> -	lli->hw[OWL_DMADESC_FLEN] = len | FCNT_VAL << 20;
>> -	lli->hw[OWL_DMADESC_CTRLB] = ctrlb;
>> +
>> +	if (od->devid == S700_DMA) {
>> +		/* Max frame length is 1MB */
>> +		lli->hw[OWL_DMADESC_FLEN] = len;
>> +		/*
>> +		 * On S700, word starts from offset 0x1C is shared between
>> +		 * frame count and ctrlb, where first 12 bits are for frame
>> +		 * count and rest of 20 bits are for ctrlb.
>> +		 */
>> +		lli->hw[OWL_DMADESC_CTRLB] = FCNT_VAL | ctrlb;
>> +	} else {
>> +		/*
>> +		 * On S900, word starts from offset 0xC is shared between
>> +		 * frame length (max frame length is 1MB) and frame count,
>> +		 * where first 20 bits are for frame length and rest of
>> +		 * 12 bits are for frame count.
>> +		 */
>> +		lli->hw[OWL_DMADESC_FLEN] = len | FCNT_VAL << 20;
>> +		lli->hw[OWL_DMADESC_CTRLB] = ctrlb;
> 
> Unfortunately this wont scale, we will keep adding new conditions for
> newer SoC's! So rather than this why not encode max frame length in
> driver_data rather than S900_DMA/S700_DMA.. In future one can add values
> for newer SoC and not code above logic again.

What newer SoCs? I don't think we should try to guess the future here.
We can always introduce further abstractions later, once we actually
*know* what we are looking at.

Besides, I don't understand what you are after. The max frame length is
1MB in both cases, it's just a matter of where to put FCNT_VAL, either
in FLEN or in CTRLB. And having an extra flag for that in driver data
sounds a bit over the top at the moment.

Cheers,
Andre.

> 
>> +static const struct of_device_id owl_dma_match[] = {
>> +	{ .compatible = "actions,s900-dma", .data = (void *)S900_DMA,},
>> +	{ .compatible = "actions,s700-dma", .data = (void *)S700_DMA,},
> 
> Is the .compatible documented, Documentation patch should come before
> the driver use patch in a series
> 
>>  static int owl_dma_probe(struct platform_device *pdev)
>>  {
>>  	struct device_node *np = pdev->dev.of_node;
>>  	struct owl_dma *od;
>>  	int ret, i, nr_channels, nr_requests;
>> +	const struct of_device_id *of_id =
>> +				of_match_device(owl_dma_match, &pdev->dev);
> 
> You care about driver_data rather than of_id, so using
> of_device_get_match_data() would be better..
> 
>>  	od = devm_kzalloc(&pdev->dev, sizeof(*od), GFP_KERNEL);
>>  	if (!od)
>> @@ -1083,6 +1116,8 @@ static int owl_dma_probe(struct platform_device *pdev)
>>  	dev_info(&pdev->dev, "dma-channels %d, dma-requests %d\n",
>>  		 nr_channels, nr_requests);
>>  
>> +	od->devid = (enum owl_dma_id)(uintptr_t)of_id->data;
> 
> Funny casts, I dont think you need uintptr_t!
> 

Re: [PATCH v4 02/10] dmaengine: Actions: Add support for S700 DMA engine

[Amit Tomer]

Hi,

On Wed, Jun 24, 2020 at 3:06 PM André Przywara <andre.przywara@arm.com> wrote:
>
> On 24/06/2020 07:15, Vinod Koul wrote:
>
> Hi,
>
> > On 09-06-20, 15:47, Amit Singh Tomar wrote:
> >
> >> @@ -372,6 +383,7 @@ static inline int owl_dma_cfg_lli(struct owl_dma_vchan *vchan,
> >>                                struct dma_slave_config *sconfig,
> >>                                bool is_cyclic)
> >>  {
> >> +    struct owl_dma *od = to_owl_dma(vchan->vc.chan.device);
> >>      u32 mode, ctrlb;
> >>
> >>      mode = OWL_DMA_MODE_PW(0);
> >> @@ -427,14 +439,26 @@ static inline int owl_dma_cfg_lli(struct owl_dma_vchan *vchan,
> >>      lli->hw[OWL_DMADESC_DADDR] = dst;
> >>      lli->hw[OWL_DMADESC_SRC_STRIDE] = 0;
> >>      lli->hw[OWL_DMADESC_DST_STRIDE] = 0;
> >> -    /*
> >> -     * Word starts from offset 0xC is shared between frame length
> >> -     * (max frame length is 1MB) and frame count, where first 20
> >> -     * bits are for frame length and rest of 12 bits are for frame
> >> -     * count.
> >> -     */
> >> -    lli->hw[OWL_DMADESC_FLEN] = len | FCNT_VAL << 20;
> >> -    lli->hw[OWL_DMADESC_CTRLB] = ctrlb;
> >> +
> >> +    if (od->devid == S700_DMA) {
> >> +            /* Max frame length is 1MB */
> >> +            lli->hw[OWL_DMADESC_FLEN] = len;
> >> +            /*
> >> +             * On S700, word starts from offset 0x1C is shared between
> >> +             * frame count and ctrlb, where first 12 bits are for frame
> >> +             * count and rest of 20 bits are for ctrlb.
> >> +             */
> >> +            lli->hw[OWL_DMADESC_CTRLB] = FCNT_VAL | ctrlb;
> >> +    } else {
> >> +            /*
> >> +             * On S900, word starts from offset 0xC is shared between
> >> +             * frame length (max frame length is 1MB) and frame count,
> >> +             * where first 20 bits are for frame length and rest of
> >> +             * 12 bits are for frame count.
> >> +             */
> >> +            lli->hw[OWL_DMADESC_FLEN] = len | FCNT_VAL << 20;
> >> +            lli->hw[OWL_DMADESC_CTRLB] = ctrlb;
> >
> > Unfortunately this wont scale, we will keep adding new conditions for
> > newer SoC's! So rather than this why not encode max frame length in
> > driver_data rather than S900_DMA/S700_DMA.. In future one can add values
> > for newer SoC and not code above logic again.
>
> What newer SoCs? I don't think we should try to guess the future here.
> We can always introduce further abstractions later, once we actually
> *know* what we are looking at.
>
Apart from it , we have *one* more SoC from Actions .i.e. S500 where
the DMA controller is
identical to S900, and requires *no* additional code to work properly.

So, I think we are safe to have the changes proposed in this patch.

Thanks

-Amit

Re: [PATCH v4 02/10] dmaengine: Actions: Add support for S700 DMA engine

[Vinod Koul]

On 24-06-20, 10:35, André Przywara wrote:
> On 24/06/2020 07:15, Vinod Koul wrote:
> > On 09-06-20, 15:47, Amit Singh Tomar wrote:
> > 
> >> @@ -372,6 +383,7 @@ static inline int owl_dma_cfg_lli(struct owl_dma_vchan *vchan,
> >>  				  struct dma_slave_config *sconfig,
> >>  				  bool is_cyclic)
> >>  {
> >> +	struct owl_dma *od = to_owl_dma(vchan->vc.chan.device);
> >>  	u32 mode, ctrlb;
> >>  
> >>  	mode = OWL_DMA_MODE_PW(0);
> >> @@ -427,14 +439,26 @@ static inline int owl_dma_cfg_lli(struct owl_dma_vchan *vchan,
> >>  	lli->hw[OWL_DMADESC_DADDR] = dst;
> >>  	lli->hw[OWL_DMADESC_SRC_STRIDE] = 0;
> >>  	lli->hw[OWL_DMADESC_DST_STRIDE] = 0;
> >> -	/*
> >> -	 * Word starts from offset 0xC is shared between frame length
> >> -	 * (max frame length is 1MB) and frame count, where first 20
> >> -	 * bits are for frame length and rest of 12 bits are for frame
> >> -	 * count.
> >> -	 */
> >> -	lli->hw[OWL_DMADESC_FLEN] = len | FCNT_VAL << 20;
> >> -	lli->hw[OWL_DMADESC_CTRLB] = ctrlb;
> >> +
> >> +	if (od->devid == S700_DMA) {
> >> +		/* Max frame length is 1MB */
> >> +		lli->hw[OWL_DMADESC_FLEN] = len;
> >> +		/*
> >> +		 * On S700, word starts from offset 0x1C is shared between
> >> +		 * frame count and ctrlb, where first 12 bits are for frame
> >> +		 * count and rest of 20 bits are for ctrlb.
> >> +		 */
> >> +		lli->hw[OWL_DMADESC_CTRLB] = FCNT_VAL | ctrlb;
> >> +	} else {
> >> +		/*
> >> +		 * On S900, word starts from offset 0xC is shared between
> >> +		 * frame length (max frame length is 1MB) and frame count,
> >> +		 * where first 20 bits are for frame length and rest of
> >> +		 * 12 bits are for frame count.
> >> +		 */
> >> +		lli->hw[OWL_DMADESC_FLEN] = len | FCNT_VAL << 20;
> >> +		lli->hw[OWL_DMADESC_CTRLB] = ctrlb;
> > 
> > Unfortunately this wont scale, we will keep adding new conditions for
> > newer SoC's! So rather than this why not encode max frame length in
> > driver_data rather than S900_DMA/S700_DMA.. In future one can add values
> > for newer SoC and not code above logic again.
> 
> What newer SoCs? I don't think we should try to guess the future here.

In a patch for adding new SoC, quite ironical I would say!

> We can always introduce further abstractions later, once we actually
> *know* what we are looking at.

Rather if we know we are adding abstractions, why not add in a way that
makes it scale better rather than rework again

> Besides, I don't understand what you are after. The max frame length is
> 1MB in both cases, it's just a matter of where to put FCNT_VAL, either
> in FLEN or in CTRLB. And having an extra flag for that in driver data
> sounds a bit over the top at the moment.

Maybe, maybe not. I would rather make it support N SoC when adding
support for second one rather than keep adding everytime a new SoC is
added...

-- 
~Vinod

Re: [PATCH v4 02/10] dmaengine: Actions: Add support for S700 DMA engine

[André Przywara]

On 29/06/2020 10:54, Vinod Koul wrote:

Hi Vinod,

> On 24-06-20, 10:35, Andr� Przywara wrote:
>> On 24/06/2020 07:15, Vinod Koul wrote:
>>> On 09-06-20, 15:47, Amit Singh Tomar wrote:
>>>
>>>> @@ -372,6 +383,7 @@ static inline int owl_dma_cfg_lli(struct owl_dma_vchan *vchan,
>>>>  				  struct dma_slave_config *sconfig,
>>>>  				  bool is_cyclic)
>>>>  {
>>>> +	struct owl_dma *od = to_owl_dma(vchan->vc.chan.device);
>>>>  	u32 mode, ctrlb;
>>>>  
>>>>  	mode = OWL_DMA_MODE_PW(0);
>>>> @@ -427,14 +439,26 @@ static inline int owl_dma_cfg_lli(struct owl_dma_vchan *vchan,
>>>>  	lli->hw[OWL_DMADESC_DADDR] = dst;
>>>>  	lli->hw[OWL_DMADESC_SRC_STRIDE] = 0;
>>>>  	lli->hw[OWL_DMADESC_DST_STRIDE] = 0;
>>>> -	/*
>>>> -	 * Word starts from offset 0xC is shared between frame length
>>>> -	 * (max frame length is 1MB) and frame count, where first 20
>>>> -	 * bits are for frame length and rest of 12 bits are for frame
>>>> -	 * count.
>>>> -	 */
>>>> -	lli->hw[OWL_DMADESC_FLEN] = len | FCNT_VAL << 20;
>>>> -	lli->hw[OWL_DMADESC_CTRLB] = ctrlb;
>>>> +
>>>> +	if (od->devid == S700_DMA) {
>>>> +		/* Max frame length is 1MB */
>>>> +		lli->hw[OWL_DMADESC_FLEN] = len;
>>>> +		/*
>>>> +		 * On S700, word starts from offset 0x1C is shared between
>>>> +		 * frame count and ctrlb, where first 12 bits are for frame
>>>> +		 * count and rest of 20 bits are for ctrlb.
>>>> +		 */
>>>> +		lli->hw[OWL_DMADESC_CTRLB] = FCNT_VAL | ctrlb;
>>>> +	} else {
>>>> +		/*
>>>> +		 * On S900, word starts from offset 0xC is shared between
>>>> +		 * frame length (max frame length is 1MB) and frame count,
>>>> +		 * where first 20 bits are for frame length and rest of
>>>> +		 * 12 bits are for frame count.
>>>> +		 */
>>>> +		lli->hw[OWL_DMADESC_FLEN] = len | FCNT_VAL << 20;
>>>> +		lli->hw[OWL_DMADESC_CTRLB] = ctrlb;
>>>
>>> Unfortunately this wont scale, we will keep adding new conditions for
>>> newer SoC's! So rather than this why not encode max frame length in
>>> driver_data rather than S900_DMA/S700_DMA.. In future one can add values
>>> for newer SoC and not code above logic again.
>>
>> What newer SoCs? I don't think we should try to guess the future here.
> 
> In a patch for adding new SoC, quite ironical I would say!

S700 is not a new SoC, it's just this driver didn't support it yet. What
I meant is that I don't even know about the existence of upcoming SoCs
(Google seems clueless), not to speak of documentation to assess which
DMA controller they use.

>> We can always introduce further abstractions later, once we actually
>> *know* what we are looking at.
> 
> Rather if we know we are adding abstractions, why not add in a way that
> makes it scale better rather than rework again

I appreciate the effort, but this really tapping around in the dark,
since we don't know which direction any new DMA controller is taking. I
might not even be similar.

>> Besides, I don't understand what you are after. The max frame length is
>> 1MB in both cases, it's just a matter of where to put FCNT_VAL, either
>> in FLEN or in CTRLB. And having an extra flag for that in driver data
>> sounds a bit over the top at the moment.
> 
> Maybe, maybe not. I would rather make it support N SoC when adding
> support for second one rather than keep adding everytime a new SoC is
> added...

Well, what do you suggest, specifically? At the moment we have two
*slightly* different DMA controllers, so we differentiate between the
two based on the model. Do you want to introduce an extra flag like
FRAME_CNT_IN_CTRLB? That seems to be a bit over the top here, since we
don't know if a future DMA controller is still compatible, or introduces
completely new differences.

Cheers,
Andre

Re: [PATCH v4 02/10] dmaengine: Actions: Add support for S700 DMA engine

[Vinod Koul]

On 29-06-20, 12:19, André Przywara wrote:
> On 29/06/2020 10:54, Vinod Koul wrote:

> >> What newer SoCs? I don't think we should try to guess the future here.
> > 
> > In a patch for adding new SoC, quite ironical I would say!
> 
> S700 is not a new SoC, it's just this driver didn't support it yet. What
> I meant is that I don't even know about the existence of upcoming SoCs
> (Google seems clueless), not to speak of documentation to assess which
> DMA controller they use.
> 
> >> We can always introduce further abstractions later, once we actually
> >> *know* what we are looking at.
> > 
> > Rather if we know we are adding abstractions, why not add in a way that
> > makes it scale better rather than rework again
> 
> I appreciate the effort, but this really tapping around in the dark,
> since we don't know which direction any new DMA controller is taking. I
> might not even be similar.
> 
> >> Besides, I don't understand what you are after. The max frame length is
> >> 1MB in both cases, it's just a matter of where to put FCNT_VAL, either
> >> in FLEN or in CTRLB. And having an extra flag for that in driver data
> >> sounds a bit over the top at the moment.
> > 
> > Maybe, maybe not. I would rather make it support N SoC when adding
> > support for second one rather than keep adding everytime a new SoC is
> > added...
> 
> Well, what do you suggest, specifically? At the moment we have two
> *slightly* different DMA controllers, so we differentiate between the
> two based on the model. Do you want to introduce an extra flag like
> FRAME_CNT_IN_CTRLB? That seems to be a bit over the top here, since we
> don't know if a future DMA controller is still compatible, or introduces
> completely new differences.

Fair enough, okay let us go with compatible for now

-- 
~Vinod

Re: [PATCH v4 02/10] dmaengine: Actions: Add support for S700 DMA engine

[Amit Tomer]

Hi Vinod,

Thanks for having a look and providing the comments.

> Is the .compatible documented, Documentation patch should come before
> the driver use patch in a series

Yes, this new compatible string is documented in patch (05/10).
I would make it as a patch (1/10).

> >  static int owl_dma_probe(struct platform_device *pdev)
> >  {
> >       struct device_node *np = pdev->dev.of_node;
> >       struct owl_dma *od;
> >       int ret, i, nr_channels, nr_requests;
> > +     const struct of_device_id *of_id =
> > +                             of_match_device(owl_dma_match, &pdev->dev);
>
> You care about driver_data rather than of_id, so using
> of_device_get_match_data() would be better..

Okay. would take care of it in next version.

> >       od = devm_kzalloc(&pdev->dev, sizeof(*od), GFP_KERNEL);
> >       if (!od)
> > @@ -1083,6 +1116,8 @@ static int owl_dma_probe(struct platform_device *pdev)
> >       dev_info(&pdev->dev, "dma-channels %d, dma-requests %d\n",
> >                nr_channels, nr_requests);
> >
> > +     od->devid = (enum owl_dma_id)(uintptr_t)of_id->data;
>
> Funny casts, I dont think you need uintptr_t!

But without this cast, clang compiler emits following warning:

warning: cast to smaller integer type 'enum owl_dma_id' from 'const void *'
          [-Wvoid-pointer-to-enum-cast]

Thanks
-Amit

Re: [PATCH v4 02/10] dmaengine: Actions: Add support for S700 DMA engine

[Vinod Koul]

On 29-06-20, 13:49, Amit Tomer wrote:
> Hi Vinod,
> 
> Thanks for having a look and providing the comments.
> 
> > Is the .compatible documented, Documentation patch should come before
> > the driver use patch in a series
> 
> Yes, this new compatible string is documented in patch (05/10).
> I would make it as a patch (1/10).
> 
> > >  static int owl_dma_probe(struct platform_device *pdev)
> > >  {
> > >       struct device_node *np = pdev->dev.of_node;
> > >       struct owl_dma *od;
> > >       int ret, i, nr_channels, nr_requests;
> > > +     const struct of_device_id *of_id =
> > > +                             of_match_device(owl_dma_match, &pdev->dev);
> >
> > You care about driver_data rather than of_id, so using
> > of_device_get_match_data() would be better..
> 
> Okay. would take care of it in next version.
> 
> > >       od = devm_kzalloc(&pdev->dev, sizeof(*od), GFP_KERNEL);
> > >       if (!od)
> > > @@ -1083,6 +1116,8 @@ static int owl_dma_probe(struct platform_device *pdev)
> > >       dev_info(&pdev->dev, "dma-channels %d, dma-requests %d\n",
> > >                nr_channels, nr_requests);
> > >
> > > +     od->devid = (enum owl_dma_id)(uintptr_t)of_id->data;
> >
> > Funny casts, I dont think you need uintptr_t!
> 
> But without this cast, clang compiler emits following warning:
> 
> warning: cast to smaller integer type 'enum owl_dma_id' from 'const void *'
>           [-Wvoid-pointer-to-enum-cast]

If you use of_device_get_match_data() you will not fall into this :)

-- 
~Vinod

Re: [PATCH v4 02/10] dmaengine: Actions: Add support for S700 DMA engine

[Amit Tomer]

Hi Vinod,

On Mon, Jun 29, 2020 at 3:22 PM Vinod Koul <vkoul@kernel.org> wrote:

> If you use of_device_get_match_data() you will not fall into this :)

But again, of_device_get_match_data() returns void *, and we need
"uintptr_t" in order to type cast it properly (at-least without
warning).

Also, while looking around found the similar warning for other file
where it uses " of_device_get_match_data()"
drivers/pci/controller/pcie-iproc-platform.c:56:15: warning: cast to
smaller integer type 'enum iproc_pcie_type' from 'const void *'
[-Wvoid-pointer-to-enum-cast]
        pcie->type = (enum iproc_pcie_type) of_device_get_match_data(dev);

Thanks
-Amit

Re: [PATCH v4 02/10] dmaengine: Actions: Add support for S700 DMA engine

[Vinod Koul]

On 30-06-20, 15:17, Amit Tomer wrote:
> Hi Vinod,
> 
> On Mon, Jun 29, 2020 at 3:22 PM Vinod Koul <vkoul@kernel.org> wrote:
> 
> > If you use of_device_get_match_data() you will not fall into this :)
> 
> But again, of_device_get_match_data() returns void *, and we need
> "uintptr_t" in order to type cast it properly (at-least without
> warning).

Not really, you can cast from void * to you own structure.. btw why do
you need uintptr_t?

> 
> Also, while looking around found the similar warning for other file
> where it uses " of_device_get_match_data()"
> drivers/pci/controller/pcie-iproc-platform.c:56:15: warning: cast to
> smaller integer type 'enum iproc_pcie_type' from 'const void *'
> [-Wvoid-pointer-to-enum-cast]
>         pcie->type = (enum iproc_pcie_type) of_device_get_match_data(dev);

The problem is a pointer to enum conversion :) I think the right way
would be to do would be below

        soc_type =  (enum foo)of_device_get_match_data(dev);

or
        soc_type =  (unsigned long) of_device_get_match_data(dev);

which I think should be fine in gcc, but possibly give you above warning
in clang.. but i thought that was fixed in clang https://reviews.llvm.org/D75758

Thanks
-- 
~Vinod

Re: [PATCH v4 02/10] dmaengine: Actions: Add support for S700 DMA engine

[Amit Tomer]

Hi,

On Tue, Jun 30, 2020 at 7:54 PM Vinod Koul <vkoul@kernel.org> wrote:
>
> On 30-06-20, 15:17, Amit Tomer wrote:
> > Hi Vinod,
> >
> > On Mon, Jun 29, 2020 at 3:22 PM Vinod Koul <vkoul@kernel.org> wrote:
> >
> > > If you use of_device_get_match_data() you will not fall into this :)
> >
> > But again, of_device_get_match_data() returns void *, and we need
> > "uintptr_t" in order to type cast it properly (at-least without
> > warning).
>
> Not really, you can cast from void * to you own structure.. btw why do
> you need uintptr_t?

uintptr_t allows us to cast to an integer type that matches with enum
in terms of size, and
clang is happy about it (no more such warnings).

> The problem is a pointer to enum conversion :) I think the right way
> would be to do would be below
>
>         soc_type =  (enum foo)of_device_get_match_data(dev);
>
> or
>         soc_type =  (unsigned long) of_device_get_match_data(dev);
>
> which I think should be fine in gcc, but possibly give you above warning

Yeah, GCC is always fine with it.

> in clang.. but i thought that was fixed in clang https://reviews.llvm.org/D75758

Thanks for pointing this out.

To be honest, I thought clang had brought something important which is
missed by GCC (via emitting this warning)
that needed to be fixed in Kernel code.

But looking at this commit[1], feeling that CLANG people just wanted
to be compatible with GCC, and
in that situation why should one believe the clang ?

[1]: https://github.com/ClangBuiltLinux/llvm-project/commit/4fd4438882cc7f78e56e147d52d9a1f63b58ba81

Thanks
-Amit