lkml.org 
[lkml]   [2019]   [Jun]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Date
    SubjectRe: [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@ti.com> wrote:
    >
    >
    > On 14/06/2019 16.20, Rob Herring wrote:
    > > 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.
    >
    > 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

    \
     
     \ /
      Last update: 2019-06-19 16:05    [W:2.568 / U:0.008 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site