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_JsqJTWNKTB1D2wNysonzasgL9awLLvr1HdOckUnQbpgsDQw@mail.gmail.com>
Date:   Wed, 19 Jun 2019 08:04:26 -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 Fri, Jun 14, 2019 at 7:42 AM Peter Ujfalusi <peter.ujfalusi@...com> wrote:
>
>
> On 14/06/2019 16.20, Rob Herring wrote:
> > 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.
>
> The channel can be either Packet or TR mode. The HW is really flexible
> on this (and on other things as well).
> It just happens that Linux need to use specific channels in a specific mode.
>
> Would it help if we assume that all channels are used in Packet mode,
> but we have linux,tr-mode bool to indicate that the given channel in
> Linux need to be used in TR mode.

Your use of 'linux' prefix is wrong. Stop using it.

> >> 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.
>
> So I should have a table for the thread IDs in the DMA driver and mark
> channels as TR or Packet in there for Linux use?

Perhaps. I haven't heard any reasons why you need this in DT. If Linux
is dictating the modes, then sounds like it should be in Linux.

But really, I don't fully understand what you are doing here to tell
you what to do beyond using 'linux' prefix is wrong.

> Or just an array which would mark the non packet PSI-L thread IDs?
>
> I still prefer to have this coming via DT as a Linux parameter as other
> OS is free to ignore the linux,udma-mode, but as I said there are
> certain channels which must be used in Linux in certain mode while
> others in different mode.

A DT client is free to ignore any DT property. You don't need a client
prefix for that.

> >> 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?
>
> This is UDMAP internal information on what type of Descriptors the
> channel will expect and how it is going to dispatch the work.
>
> Packet and TR mode at the end does the same thing, but in a completely
> different way.
>
> - Péter
>
> Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
> Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki