[0/3] dt-bindings: dma: ti: k3* : Update optional reg regions

  DMAs on TI K3 SoCs have channel configuration registers region which are
usually hidden from Linux and configured via Device Manager Firmware
APIs. But certain early SWs like bootloader which run before Device
Manager is fully up would need to directly configure these registers and
thus require to be in DT description.

This add bindings for such configuration regions.  Backward
compatibility is maintained to existing DT by only mandating existing
regions to be present and this new region as optional.

Vignesh Raghavendra (3):
  dt-bindings: dma: ti: k3-bcdma: Describe cfg register regions
  dt-bindings: dma: ti: k3-pktdma: Describe cfg register regions
  dt-bindings: dma: ti: k3-udma: Describe cfg register regions

 .../devicetree/bindings/dma/ti/k3-bcdma.yaml  | 25 +++++++++++++------
 .../devicetree/bindings/dma/ti/k3-pktdma.yaml | 18 ++++++++++---
 .../devicetree/bindings/dma/ti/k3-udma.yaml   | 14 ++++++++---
 3 files changed, 43 insertions(+), 14 deletions(-)
  

On Thu, Aug 10, 2023 at 11:13:53PM +0530, Vignesh Raghavendra wrote:
> Block copy DMA(BCDMA)module on K3 SoCs have ring cfg, TX and RX
> channel cfg register regions which are usually configured by a Device
> Management firmware. But certain entities such as bootloader (like
> U-Boot) may have to access them directly. Describe this region in the
> binding documentation for completeness of module description.
> 
> Keep the binding compatible with existing DTS files by requiring first
> five regions to be present at least.
> 
> Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
> ---
>  .../devicetree/bindings/dma/ti/k3-bcdma.yaml  | 25 +++++++++++++------
>  1 file changed, 17 insertions(+), 8 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/dma/ti/k3-bcdma.yaml b/Documentation/devicetree/bindings/dma/ti/k3-bcdma.yaml
> index 4ca300a42a99..d166e284532b 100644
> --- a/Documentation/devicetree/bindings/dma/ti/k3-bcdma.yaml
> +++ b/Documentation/devicetree/bindings/dma/ti/k3-bcdma.yaml
> @@ -37,11 +37,11 @@ properties:
>  
>    reg:
>      minItems: 3
> -    maxItems: 5
> +    maxItems: 8

How come none of these reg entries have a description? What
differentiates a "gcfg" from a "cfg" for example?

>  
>    reg-names:
>      minItems: 3
> -    maxItems: 5
> +    maxItems: 8
>  
>    "#dma-cells":
>      const: 3
> @@ -161,14 +161,19 @@ allOf:
>        properties:
>          reg:
>            minItems: 5
> +          maxItems: 8
>  
>          reg-names:
> +          minItems: 5
>            items:
>              - const: gcfg
>              - const: bchanrt
>              - const: rchanrt
>              - const: tchanrt
>              - const: ringrt
> +            - const: cfg
> +            - const: tchan
> +            - const: rchan
>  
>        required:
>          - ti,sci-rm-range-bchan
> @@ -216,12 +221,16 @@ examples:
>              main_bcdma: dma-controller@485c0100 {
>                  compatible = "ti,am64-dmss-bcdma";
>  
> -                reg = <0x0 0x485c0100 0x0 0x100>,
> -                      <0x0 0x4c000000 0x0 0x20000>,
> -                      <0x0 0x4a820000 0x0 0x20000>,
> -                      <0x0 0x4aa40000 0x0 0x20000>,
> -                      <0x0 0x4bc00000 0x0 0x100000>;
> -                reg-names = "gcfg", "bchanrt", "rchanrt", "tchanrt", "ringrt";
> +                reg = <0x00 0x485c0100 0x00 0x100>,

Why have you added extra zeros? (0x00)

Thanks,
Conor.

> +                      <0x00 0x4c000000 0x00 0x20000>,
> +                      <0x00 0x4a820000 0x00 0x20000>,
> +                      <0x00 0x4aa40000 0x00 0x20000>,
> +                      <0x00 0x4bc00000 0x00 0x100000>,
> +                      <0x00 0x48600000 0x00 0x8000>,
> +                      <0x00 0x484a4000 0x00 0x2000>,
> +                      <0x00 0x484c2000 0x00 0x2000>;
> +                reg-names = "gcfg", "bchanrt", "rchanrt", "tchanrt", "ringrt",
> +                            "cfg", "tchan", "rchan";
>                  msi-parent = <&inta_main_dmss>;
>                  #dma-cells = <3>;
>  
> -- 
> 2.41.0
>
  

Vignesh,

On 10/08/2023 20:43, Vignesh Raghavendra wrote:
> DMAs on TI K3 SoCs have channel configuration registers region which are
> usually hidden from Linux and configured via Device Manager Firmware
> APIs. But certain early SWs like bootloader which run before Device
> Manager is fully up would need to directly configure these registers and
> thus require to be in DT description.
> 
> This add bindings for such configuration regions.  Backward
> compatibility is maintained to existing DT by only mandating existing
> regions to be present and this new region as optional.

These regions were 'hidden' from Linux or other open coded access for a 
reason.
If I recall the main reason is security and the need to make sure that 
the allocation of the channels not been violated.

IMho the boot loader should be no exception and it should be using the 
DM firmware to configure the DMAs.

Or has the security concern been dropped and SW can do whatever it wants?

> 
> Vignesh Raghavendra (3):
>    dt-bindings: dma: ti: k3-bcdma: Describe cfg register regions
>    dt-bindings: dma: ti: k3-pktdma: Describe cfg register regions
>    dt-bindings: dma: ti: k3-udma: Describe cfg register regions
> 
>   .../devicetree/bindings/dma/ti/k3-bcdma.yaml  | 25 +++++++++++++------
>   .../devicetree/bindings/dma/ti/k3-pktdma.yaml | 18 ++++++++++---
>   .../devicetree/bindings/dma/ti/k3-udma.yaml   | 14 ++++++++---
>   3 files changed, 43 insertions(+), 14 deletions(-)
>
  

Hi Peter,

On 11/08/23 20:46, Péter Ujfalusi wrote:
> Vignesh,
> 
> On 10/08/2023 20:43, Vignesh Raghavendra wrote:
>> DMAs on TI K3 SoCs have channel configuration registers region which are
>> usually hidden from Linux and configured via Device Manager Firmware
>> APIs. But certain early SWs like bootloader which run before Device
>> Manager is fully up would need to directly configure these registers and
>> thus require to be in DT description.
>>
>> This add bindings for such configuration regions.  Backward
>> compatibility is maintained to existing DT by only mandating existing
>> regions to be present and this new region as optional.
> 
> These regions were 'hidden' from Linux or other open coded access for a
> reason.
> If I recall the main reason is security and the need to make sure that
> the allocation of the channels not been violated.
> 
> IMho the boot loader should be no exception and it should be using the
> DM firmware to configure the DMAs.
> 
> Or has the security concern been dropped and SW can do whatever it wants?

There is been a relook at the arch post this driver was upstreamed. 
System firmware (SYSFW) is now two separate components:  TI Foundational 
Security (TIFS) running in a secure island and Device Management (DM) 
firmware (runs on boot R5 core) [0] shows boot flow diagram for AM62x.

Security critical items such as PSIL pairing, channel firewalls and 
credential configurations are under TIFS and is handled via TI SCI calls 
at all times.

But, things related to resource configuration (to ensure different cores 
dont step on each other) is under DM. Linux still needs to talk to DM 
for configuring these regions. But, when primary bootloader (R5 SPL) is 
running, there isn't a DM firmware (as it runs on the same core after R5 
SPL), it would need to configure DMA resources on its own. 

This update is mainly to aid R5 SPL to reuse kernel DT as is. 
Hope that helps


[0] https://u-boot.readthedocs.io/en/latest/board/ti/am62x_sk.html?highlight=am62#boot-flow
(Similar boot flow for rest of K3 devices barring am65 and am64)

> 
>>
>> Vignesh Raghavendra (3):
>>    dt-bindings: dma: ti: k3-bcdma: Describe cfg register regions
>>    dt-bindings: dma: ti: k3-pktdma: Describe cfg register regions
>>    dt-bindings: dma: ti: k3-udma: Describe cfg register regions
>>
>>   .../devicetree/bindings/dma/ti/k3-bcdma.yaml  | 25 +++++++++++++------
>>   .../devicetree/bindings/dma/ti/k3-pktdma.yaml | 18 ++++++++++---
>>   .../devicetree/bindings/dma/ti/k3-udma.yaml   | 14 ++++++++---
>>   3 files changed, 43 insertions(+), 14 deletions(-)
>>
>