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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAL_JsqJNMkKL_FubZfjKY6jLebMetmgR24EoendHoPM2ckrUQA@mail.gmail.com>
Date:   Fri, 14 Jun 2019 07:20:57 -0600
From:   Rob Herring <robh@...nel.org>
To:     Peter Ujfalusi <peter.ujfalusi@...com>
Cc:     Vinod <vkoul@...nel.org>, Nishanth Menon <nm@...com>,
        Santosh Shilimkar <ssantosh@...nel.org>,
        Dan Williams <dan.j.williams@...el.com>,
        "open list:DMA GENERIC OFFLOAD ENGINE SUBSYSTEM" 
        <dmaengine@...r.kernel.org>,
        "moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE" 
        <linux-arm-kernel@...ts.infradead.org>, devicetree@...r.kernel.org,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Grygorii Strashko <grygorii.strashko@...com>,
        Lokesh Vutla <lokeshvutla@...com>,
        Tero Kristo <t-kristo@...com>, Tony Lindgren <tony@...mide.com>
Subject: Re: [PATCH 09/16] dt-bindings: dma: ti: Add document for K3 UDMA

On Thu, Jun 13, 2019 at 2:33 PM Peter Ujfalusi <peter.ujfalusi@...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