linux-phytec-ti

dmaengine: ti: k3-udma: rework rflow management code

Now the K3 UDMA rflow management code is a little bit entangled an and uses
one bitmask rflow_map as to specify available UDMA RX Flows as RX Flows
which are in use.
It also doesn't allow to request remote RX Flows which are owned by FW
running on Remote Processor Cores (RPC). In such cases, FW owns RX UDMA
channel and provides Linux with set of RX Flow ID which can be used for
ingress traffic processing which designed for Linux only. Many RPCs can be
clients of the same RX UDMA channel. In this case TI-SCI resource
management provides access to the same range of resources (RX flows) to all
CPU Cores uses RX UDMA channel (including Linux Core), but, unfortunately,
there is no way now to specify such configuration in board config file and
to make TI SCI API to return proper resource's ranges to the Linux. The DT
also can't be used as this is SW configuration.

This patch introduces solution for the above by allowing to request any
RX Flow by ID in the following way:
- add rflow_in_use and use it exclusively to mark RX flows which are in use
  now by Linux. This mask is updated by __udma_get/put_rflow() API.

- change meaning of rflow_map and rename it to rflow_gp_map: it defines now
  the ranges of generic purpose RX flows which exclusively assigned and
  managed by Linux (0 bits).
  This range is provided by TI-SCI FW.

- rename xxx_reserve/free_rflow_range() to xxx_alloc/free_gp_rflow_range()
  as they are actually performing allocation of GP RX UDMA Flows.

- add requirement that GP RX Flow(s) should always be allocated first,
  before usage. Hence update the UDMA glue layer:
  -- introduce new K3 UDMA private API xudma_rflow_is_gp() to check is RX
     flow belongs to the GP RX Flows range
  -- perform RX flows allocation in case flow_id_base belongs to GP RX
     Flows range or -1 (dynamic allocation), or use RX flows IDs directly
     if provided by caller.

- change _udma_get_rflow() logic, so the RX flow can be requested by RX
  Flow ID only and if:
  -- RX Flow ID fits K3 UDMA HW RX Flow range;
  -- it is not in "in use" state;
  -- it is GP RX Flow ID and this RX Flow was previously allocated by
     __udma_alloc_gp_rflow_range() API.

The above approach is overall safe from user mistakes as TI-SCI FW will
perform additional permission checks and prohibit HW access for RX flows
which this CPU core is not allowed to access.

After this change the UDMA glue layer clients will be able:
 - request set of GP RX Flows dynamically
 - request set of GP RX Flows statically by specifying
   struct k3_nav_udmax_rx_channel_cfg->flow_id_base
 - request default RX Flow by setting
   struct k3_nav_udmax_rx_channel_cfg->flow_id_use_rxchan_id = true
 - request any other flows by ID

Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
Acked-by: Peter Ujfalusi <peter.ujfalusi@ti.com>