Re: [PATCH 09/16] dt-bindings: dma: ti: Add document for K3 UDMA

[Rob Herring <robh@kernel.org>]

On Thu, Jun 13, 2019 at 2:33 PM Peter Ujfalusi <peter.ujfalusi@ti.com> wrote:
>
> Rob,
>
> On 13/06/2019 21.16, Rob Herring wrote:
> >> +Remote PSI-L endpoint
> >> +
> >> +Required properties:
> >> +--------------------
> >> +- ti,psil-base:             PSI-L thread ID base of the endpoint
> >> +
> >> +Within the PSI-L endpoint node thread configuration subnodes must present with:
> >> +ti,psil-configX naming convention, where X is the thread ID offset.
> >
> > Don't use vendor prefixes on node names.
>
> OK.
>
> >> +
> >> +Configuration node Required properties:
> >> +--------------------
> >> +- linux,udma-mode:  Channel mode, can be:
> >> +                    - UDMA_PKT_MODE: for Packet mode channels (peripherals)
> >> +                    - UDMA_TR_MODE: for Third-Party mode
> >
> > This is hardly a common linux thing. What determines the value here.
>
> Unfortunately it is.

No, it's a feature of your h/w and in no way is something linux
defined which is the point of 'linux' prefix.

> Each channel can be configured to Packet or TR mode. For some
> peripherals it is true that they only support packet mode, these are the
> newer PSI-L native peripherals.
> For these channels a udma-mode property would be correct.
>
> But we have legacy peripherals as well and they are serviced by PDMA
> (which is a native peripheral designed to talk to the given legacy IP).
> We can use either packet or TR mode in UDMAP to talk to PDMAs, it is in
> most cases clear what to use, but for example for audio (McASP) channels
> Linux is using TR channel because we need cyclic DMA while for example
> RTOS is using Packet mode as it fits their needs better.
>
> Here I need to prefix the udma-mode with linux as the mode is used by
> Linux, but other OS might opt to use different channel mode.

So you'd need <os>,udma-mode? That doesn't work... If the setting is
per OS, then it belongs in the OS because the same dtb should work
across OS's.

> The reason why this needs to be in the DT is that when the channel is
> requested we need to configure the mode and it can not be swapped
> runtime easily between Packet and TR mode.

So when the client makes the channel request, why doesn't it specify the mode?

Rob