stm32-dma3 driver refactors the linked-list in order to address the memory
with the highest possible data width.
It means that it can introduce up to 2 linked-list items. One with a
transfer length multiple of channel maximum burst length and so with the
highest possible data width. And an extra one with the latest bytes, with
lower data width.
Some devices (e.g. FMC ECC) don't support having several transfers instead
of only one.
So add the possibility to prevent linked-list refactoring, by setting bit
17 of the 'DMA transfer requirements' bit mask.

Signed-off-by: Amelie Delaunay <amelie.delaunay@foss.st.com>
---
 Documentation/devicetree/bindings/dma/stm32/st,stm32-dma3.yaml | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/Documentation/devicetree/bindings/dma/stm32/st,stm32-dma3.yaml b/Documentation/devicetree/bindings/dma/stm32/st,stm32-dma3.yaml
index 5484848735f8ac3d2050104bbab1d986e82ba6a7..38c30271f732e0c8da48199a224a88bb647eeca7 100644
--- a/Documentation/devicetree/bindings/dma/stm32/st,stm32-dma3.yaml
+++ b/Documentation/devicetree/bindings/dma/stm32/st,stm32-dma3.yaml
@@ -99,6 +99,9 @@ properties:
         -bit 16: Prevent packing/unpacking mode
           0x0: pack/unpack enabled when source data width/burst != destination data width/burst
           0x1: memory data width/burst forced to peripheral data width/burst to prevent pack/unpack
+        -bit 17: Prevent linked-list refactoring
+          0x0: don't prevent driver to refactor the linked-list for optimal performance
+          0x1: prevent driver to refactor the linked-list, despite not optimal performance
 
 required:
   - compatible

-- 
2.25.1

On Thu, Oct 10, 2024 at 04:27:54PM +0200, Amelie Delaunay wrote:
> stm32-dma3 driver refactors the linked-list in order to address the memory
> with the highest possible data width.
> It means that it can introduce up to 2 linked-list items. One with a
> transfer length multiple of channel maximum burst length and so with the
> highest possible data width. And an extra one with the latest bytes, with
> lower data width.
> Some devices (e.g. FMC ECC) don't support having several transfers instead
> of only one.
> So add the possibility to prevent linked-list refactoring, by setting bit
> 17 of the 'DMA transfer requirements' bit mask.
> 
> Signed-off-by: Amelie Delaunay <amelie.delaunay@foss.st.com>
> ---
>  Documentation/devicetree/bindings/dma/stm32/st,stm32-dma3.yaml | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/dma/stm32/st,stm32-dma3.yaml b/Documentation/devicetree/bindings/dma/stm32/st,stm32-dma3.yaml
> index 5484848735f8ac3d2050104bbab1d986e82ba6a7..38c30271f732e0c8da48199a224a88bb647eeca7 100644
> --- a/Documentation/devicetree/bindings/dma/stm32/st,stm32-dma3.yaml
> +++ b/Documentation/devicetree/bindings/dma/stm32/st,stm32-dma3.yaml
> @@ -99,6 +99,9 @@ properties:
>          -bit 16: Prevent packing/unpacking mode
>            0x0: pack/unpack enabled when source data width/burst != destination data width/burst
>            0x1: memory data width/burst forced to peripheral data width/burst to prevent pack/unpack
> +        -bit 17: Prevent linked-list refactoring
> +          0x0: don't prevent driver to refactor the linked-list for optimal performance
> +          0x1: prevent driver to refactor the linked-list, despite not optimal performance

Driver settings don't belong in DT. Perhaps reword it in terms of h/w 
constraints (i.e. single transfer limitation).

>  
>  required:
>    - compatible
> 
> -- 
> 2.25.1
>

On 10/10/24 20:14, Rob Herring wrote:
> On Thu, Oct 10, 2024 at 04:27:54PM +0200, Amelie Delaunay wrote:
>> stm32-dma3 driver refactors the linked-list in order to address the memory
>> with the highest possible data width.
>> It means that it can introduce up to 2 linked-list items. One with a
>> transfer length multiple of channel maximum burst length and so with the
>> highest possible data width. And an extra one with the latest bytes, with
>> lower data width.
>> Some devices (e.g. FMC ECC) don't support having several transfers instead
>> of only one.
>> So add the possibility to prevent linked-list refactoring, by setting bit
>> 17 of the 'DMA transfer requirements' bit mask.
>>
>> Signed-off-by: Amelie Delaunay <amelie.delaunay@foss.st.com>
>> ---
>>   Documentation/devicetree/bindings/dma/stm32/st,stm32-dma3.yaml | 3 +++
>>   1 file changed, 3 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/dma/stm32/st,stm32-dma3.yaml b/Documentation/devicetree/bindings/dma/stm32/st,stm32-dma3.yaml
>> index 5484848735f8ac3d2050104bbab1d986e82ba6a7..38c30271f732e0c8da48199a224a88bb647eeca7 100644
>> --- a/Documentation/devicetree/bindings/dma/stm32/st,stm32-dma3.yaml
>> +++ b/Documentation/devicetree/bindings/dma/stm32/st,stm32-dma3.yaml
>> @@ -99,6 +99,9 @@ properties:
>>           -bit 16: Prevent packing/unpacking mode
>>             0x0: pack/unpack enabled when source data width/burst != destination data width/burst
>>             0x1: memory data width/burst forced to peripheral data width/burst to prevent pack/unpack
>> +        -bit 17: Prevent linked-list refactoring
>> +          0x0: don't prevent driver to refactor the linked-list for optimal performance
>> +          0x1: prevent driver to refactor the linked-list, despite not optimal performance
> 
> Driver settings don't belong in DT. Perhaps reword it in terms of h/w
> constraints (i.e. single transfer limitation).
> 

Thanks for the review and suggestion. I'll reword it in V2. Indeed, it 
is due to single transfer limitation, e.g. for ECC status registers 
transfer.

-bit 17: Prevent additional transfers due to linked-list refactoring
   0x0: don't prevent additional transfers for optimal performance
   0x1: prevent additional transfers to accommodate user constraints 
such as single transfer


Regards,
Amelie

>>   
>>   required:
>>     - compatible
>>
>> -- 
>> 2.25.1
>>