| Message ID | 20190506123456.6777-10-peter.ujfalusi@ti.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | dmaengine/soc/firmware: Add Texas Instruments UDMA support | expand |
On Mon, May 06, 2019 at 03:34:49PM +0300, Peter Ujfalusi wrote: > New binding document for > Texas Instruments K3 NAVSS Unified DMA – Peripheral Root Complex (UDMA-P). > > UDMA-P is introduced as part of the K3 architecture and can be found on > AM65x SoC. > > Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> > --- > .../devicetree/bindings/dma/ti/k3-udma.txt | 134 ++++++++++++++++++ > 1 file changed, 134 insertions(+) > create mode 100644 Documentation/devicetree/bindings/dma/ti/k3-udma.txt > > diff --git a/Documentation/devicetree/bindings/dma/ti/k3-udma.txt b/Documentation/devicetree/bindings/dma/ti/k3-udma.txt > new file mode 100644 > index 000000000000..b221a5ea119c > --- /dev/null > +++ b/Documentation/devicetree/bindings/dma/ti/k3-udma.txt > @@ -0,0 +1,134 @@ > +* Texas Instruments K3 NAVSS Unified DMA – Peripheral Root Complex (UDMA-P) > + > +The UDMA-P is intended to perform similar (but significantly upgraded) functions > +as the packet-oriented DMA used on previous SoC devices. The UDMA-P module > +supports the transmission and reception of various packet types. The UDMA-P is > +architected to facilitate the segmentation and reassembly of SoC DMA data > +structure compliant packets to/from smaller data blocks that are natively > +compatible with the specific requirements of each connected peripheral. Multiple > +Tx and Rx channels are provided within the DMA which allow multiple segmentation > +or reassembly operations to be ongoing. The DMA controller maintains state > +information for each of the channels which allows packet segmentation and > +reassembly operations to be time division multiplexed between channels in order > +to share the underlying DMA hardware. An external DMA scheduler is used to > +control the ordering and rate at which this multiplexing occurs for Transmit > +operations. The ordering and rate of Receive operations is indirectly controlled > +by the order in which blocks are pushed into the DMA on the Rx PSI-L interface. > + > +The UDMA-P also supports acting as both a UTC and UDMA-C for its internal > +channels. Channels in the UDMA-P can be configured to be either Packet-Based or > +Third-Party channels on a channel by channel basis. > + > +Required properties: > +-------------------- > +- compatible: Should be > + "ti,am654-navss-main-udmap" for am654 main NAVSS UDMAP > + "ti,am654-navss-mcu-udmap" for am654 mcu NAVSS UDMAP > +- #dma-cells: Should be set to <3>. > + - The first parameter is a phandle to the remote PSI-L > + endpoint > + - The second parameter is the thread offset within the > + remote thread ID range > + - The third parameter is the channel direction. > +- reg: Memory map of UDMAP > +- reg-names: "gcfg", "rchanrt", "tchanrt" > +- msi-parent: phandle for "ti,sci-inta" interrupt controller > +- ti,ringacc: phandle for the ring accelerator node > +- ti,psil-base: PSI-L thread ID base of the UDMAP channels > +- ti,sci: phandle on TI-SCI compatible System controller node > +- ti,sci-dev-id: TI-SCI device id > +- ti,sci-rm-range-tchan: UDMA tchan resource list in pairs of type and subtype > +- ti,sci-rm-range-rchan: UDMA rchan resource list in pairs of type and subtype > +- ti,sci-rm-range-rflow: UDMA rflow resource list in pairs of type and subtype > + > +For PSI-L thread management the parent NAVSS node must have: > +- ti,sci: phandle on TI-SCI compatible System controller node > +- ti,sci-dev-id: TI-SCI device id of the NAVSS instance > + > +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. > + > +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. > + > +Configuration node Optional properties: > +-------------------- > +- statictr-type: In case the remote endpoint requires StaticTR > + configuration: > + - PSIL_STATIC_TR_XY: XY type of StaticTR > + - PSIL_STATIC_TR_MCAN: MCAN type of StaticTR > +- ti,channel-tpl: Channel Throughput level: > + 0 / or not present - normal channel > + 1 - High Throughput channel > +- ti,needs-epib: If the endpoint require EPIB to be present in the > + descriptor. > +- ti,psd-size: Size of the Protocol Specific Data section of the > + descriptor. You've got a lot of properties and child nodes here, but not in the example. Please make the example more complete. > + > +Example: > + > +main_navss: main_navss { > + compatible = "simple-bus"; > + #address-cells = <2>; > + #size-cells = <2>; > + dma-coherent; > + dma-ranges; > + ranges; > + > + ti,sci = <&dmsc>; > + ti,sci-dev-id = <118>; > + > + main_udmap: udmap@31150000 { dma-controller@... > + compatible = "ti,am654-navss-main-udmap"; > + reg = <0x0 0x31150000 0x0 0x100>, > + <0x0 0x34000000 0x0 0x100000>, > + <0x0 0x35000000 0x0 0x100000>; > + reg-names = "gcfg", "rchanrt", "tchanrt"; > + #dma-cells = <3>; > + > + ti,ringacc = <&ringacc>; > + ti,psil-base = <0x1000>; > + > + interrupt-parent = <&main_udmass_inta>; > + > + ti,sci = <&dmsc>; > + ti,sci-dev-id = <188>; > + > + ti,sci-rm-range-tchan = <0x6 0x1>, /* TX_HCHAN */ > + <0x6 0x2>; /* TX_CHAN */ > + ti,sci-rm-range-rchan = <0x6 0x4>, /* RX_HCHAN */ > + <0x6 0x5>; /* RX_CHAN */ > + ti,sci-rm-range-rflow = <0x6 0x6>; /* GP RFLOW */ > + }; > +}; > + > +pdma0: pdma@2a41000 { > + compatible = "ti,am654-pdma"; > + reg = <0x0 0x02A41000 0x0 0x400>; > + reg-names = "eccaggr_cfg"; > + > + ti,psil-base = <0x4400>; > + > + /* ti,psil-config0-2 */ > + UDMA_PDMA_TR_XY(0); What is this? Don't abuse defines with stuff like this. Generally only defines of single values should be used. > + UDMA_PDMA_TR_XY(1); > + UDMA_PDMA_TR_XY(2); > +}; > + > +mcasp0: mcasp@02B00000 { > +... > + /* tx: pdma0-0, rx: pdma0-0 */ > + dmas = <&main_udmap &pdma0 0 UDMA_DIR_TX>, > + <&main_udmap &pdma0 0 UDMA_DIR_RX>; > + dma-names = "tx", "rx"; > +... > +}; > -- > Peter > > Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. > Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki >
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. 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. 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. >> + >> +Configuration node Optional properties: >> +-------------------- >> +- statictr-type: In case the remote endpoint requires StaticTR >> + configuration: >> + - PSIL_STATIC_TR_XY: XY type of StaticTR >> + - PSIL_STATIC_TR_MCAN: MCAN type of StaticTR >> +- ti,channel-tpl: Channel Throughput level: >> + 0 / or not present - normal channel >> + 1 - High Throughput channel >> +- ti,needs-epib: If the endpoint require EPIB to be present in the >> + descriptor. >> +- ti,psd-size: Size of the Protocol Specific Data section of the >> + descriptor. > > You've got a lot of properties and child nodes here, but not in the > example. Please make the example more complete. Sure, I'll extend the example with other peripheral which uses more properties. > >> + >> +Example: >> + >> +main_navss: main_navss { >> + compatible = "simple-bus"; >> + #address-cells = <2>; >> + #size-cells = <2>; >> + dma-coherent; >> + dma-ranges; >> + ranges; >> + >> + ti,sci = <&dmsc>; >> + ti,sci-dev-id = <118>; >> + >> + main_udmap: udmap@31150000 { > > dma-controller@... OK >> + compatible = "ti,am654-navss-main-udmap"; >> + reg = <0x0 0x31150000 0x0 0x100>, >> + <0x0 0x34000000 0x0 0x100000>, >> + <0x0 0x35000000 0x0 0x100000>; >> + reg-names = "gcfg", "rchanrt", "tchanrt"; >> + #dma-cells = <3>; >> + >> + ti,ringacc = <&ringacc>; >> + ti,psil-base = <0x1000>; >> + >> + interrupt-parent = <&main_udmass_inta>; >> + >> + ti,sci = <&dmsc>; >> + ti,sci-dev-id = <188>; >> + >> + ti,sci-rm-range-tchan = <0x6 0x1>, /* TX_HCHAN */ >> + <0x6 0x2>; /* TX_CHAN */ >> + ti,sci-rm-range-rchan = <0x6 0x4>, /* RX_HCHAN */ >> + <0x6 0x5>; /* RX_CHAN */ >> + ti,sci-rm-range-rflow = <0x6 0x6>; /* GP RFLOW */ >> + }; >> +}; >> + >> +pdma0: pdma@2a41000 { >> + compatible = "ti,am654-pdma"; >> + reg = <0x0 0x02A41000 0x0 0x400>; >> + reg-names = "eccaggr_cfg"; >> + >> + ti,psil-base = <0x4400>; >> + >> + /* ti,psil-config0-2 */ >> + UDMA_PDMA_TR_XY(0); > > What is this? Don't abuse defines with stuff like this. Generally only > defines of single values should be used. The reason I have used define to build the psil-config sections is that we have some PDMAs with 22 threads and it makes the DT explode when writing out all of the thread configurations. Within one PDMA we can have a mix of different modes, so I can not say that all of the threads in the PDMA is the same. > >> + UDMA_PDMA_TR_XY(1); >> + UDMA_PDMA_TR_XY(2); >> +}; >> + >> +mcasp0: mcasp@02B00000 { >> +... >> + /* tx: pdma0-0, rx: pdma0-0 */ >> + dmas = <&main_udmap &pdma0 0 UDMA_DIR_TX>, >> + <&main_udmap &pdma0 0 UDMA_DIR_RX>; >> + dma-names = "tx", "rx"; >> +... >> +}; >> -- Thanks, - Péter Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
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
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. >> 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? 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. >> 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
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
On 19/06/2019 17.04, Rob Herring wrote: > 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. OK, I can not argue with that. I'll have 'tr-mode' bool to indicate that the channel should be configured in TR mode for the given thread. >>>> 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. We have certain peripherals (McASP/UART/McSPI/etc) which is serviced by PDMAs to be compatible with the data movement architecture implemented within NAVSS. Unlike native peripherals, like networking we can configure the UDMAP channel to either Packet or TR mode. There are differences between the two modes, but the job can be done in both modes. In Linux we use TR mode for audio channels as it provides the needed functionality we need (efficient cyclic mode, can disable interrupts). There is no information from the HW on how a given thread is best used and other OSs can opt for not optimal use. But the majority of threads are better served in Packet mode, so adding a bool flag to the thread configuration to indicate that TR mode is the advised mode for it is perfectly fine. - Péter Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
diff --git a/Documentation/devicetree/bindings/dma/ti/k3-udma.txt b/Documentation/devicetree/bindings/dma/ti/k3-udma.txt new file mode 100644 index 000000000000..b221a5ea119c --- /dev/null +++ b/Documentation/devicetree/bindings/dma/ti/k3-udma.txt @@ -0,0 +1,134 @@ +* Texas Instruments K3 NAVSS Unified DMA – Peripheral Root Complex (UDMA-P) + +The UDMA-P is intended to perform similar (but significantly upgraded) functions +as the packet-oriented DMA used on previous SoC devices. The UDMA-P module +supports the transmission and reception of various packet types. The UDMA-P is +architected to facilitate the segmentation and reassembly of SoC DMA data +structure compliant packets to/from smaller data blocks that are natively +compatible with the specific requirements of each connected peripheral. Multiple +Tx and Rx channels are provided within the DMA which allow multiple segmentation +or reassembly operations to be ongoing. The DMA controller maintains state +information for each of the channels which allows packet segmentation and +reassembly operations to be time division multiplexed between channels in order +to share the underlying DMA hardware. An external DMA scheduler is used to +control the ordering and rate at which this multiplexing occurs for Transmit +operations. The ordering and rate of Receive operations is indirectly controlled +by the order in which blocks are pushed into the DMA on the Rx PSI-L interface. + +The UDMA-P also supports acting as both a UTC and UDMA-C for its internal +channels. Channels in the UDMA-P can be configured to be either Packet-Based or +Third-Party channels on a channel by channel basis. + +Required properties: +-------------------- +- compatible: Should be + "ti,am654-navss-main-udmap" for am654 main NAVSS UDMAP + "ti,am654-navss-mcu-udmap" for am654 mcu NAVSS UDMAP +- #dma-cells: Should be set to <3>. + - The first parameter is a phandle to the remote PSI-L + endpoint + - The second parameter is the thread offset within the + remote thread ID range + - The third parameter is the channel direction. +- reg: Memory map of UDMAP +- reg-names: "gcfg", "rchanrt", "tchanrt" +- msi-parent: phandle for "ti,sci-inta" interrupt controller +- ti,ringacc: phandle for the ring accelerator node +- ti,psil-base: PSI-L thread ID base of the UDMAP channels +- ti,sci: phandle on TI-SCI compatible System controller node +- ti,sci-dev-id: TI-SCI device id +- ti,sci-rm-range-tchan: UDMA tchan resource list in pairs of type and subtype +- ti,sci-rm-range-rchan: UDMA rchan resource list in pairs of type and subtype +- ti,sci-rm-range-rflow: UDMA rflow resource list in pairs of type and subtype + +For PSI-L thread management the parent NAVSS node must have: +- ti,sci: phandle on TI-SCI compatible System controller node +- ti,sci-dev-id: TI-SCI device id of the NAVSS instance + +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. + +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 + +Configuration node Optional properties: +-------------------- +- statictr-type: In case the remote endpoint requires StaticTR + configuration: + - PSIL_STATIC_TR_XY: XY type of StaticTR + - PSIL_STATIC_TR_MCAN: MCAN type of StaticTR +- ti,channel-tpl: Channel Throughput level: + 0 / or not present - normal channel + 1 - High Throughput channel +- ti,needs-epib: If the endpoint require EPIB to be present in the + descriptor. +- ti,psd-size: Size of the Protocol Specific Data section of the + descriptor. + +Example: + +main_navss: main_navss { + compatible = "simple-bus"; + #address-cells = <2>; + #size-cells = <2>; + dma-coherent; + dma-ranges; + ranges; + + ti,sci = <&dmsc>; + ti,sci-dev-id = <118>; + + main_udmap: udmap@31150000 { + compatible = "ti,am654-navss-main-udmap"; + reg = <0x0 0x31150000 0x0 0x100>, + <0x0 0x34000000 0x0 0x100000>, + <0x0 0x35000000 0x0 0x100000>; + reg-names = "gcfg", "rchanrt", "tchanrt"; + #dma-cells = <3>; + + ti,ringacc = <&ringacc>; + ti,psil-base = <0x1000>; + + interrupt-parent = <&main_udmass_inta>; + + ti,sci = <&dmsc>; + ti,sci-dev-id = <188>; + + ti,sci-rm-range-tchan = <0x6 0x1>, /* TX_HCHAN */ + <0x6 0x2>; /* TX_CHAN */ + ti,sci-rm-range-rchan = <0x6 0x4>, /* RX_HCHAN */ + <0x6 0x5>; /* RX_CHAN */ + ti,sci-rm-range-rflow = <0x6 0x6>; /* GP RFLOW */ + }; +}; + +pdma0: pdma@2a41000 { + compatible = "ti,am654-pdma"; + reg = <0x0 0x02A41000 0x0 0x400>; + reg-names = "eccaggr_cfg"; + + ti,psil-base = <0x4400>; + + /* ti,psil-config0-2 */ + UDMA_PDMA_TR_XY(0); + UDMA_PDMA_TR_XY(1); + UDMA_PDMA_TR_XY(2); +}; + +mcasp0: mcasp@02B00000 { +... + /* tx: pdma0-0, rx: pdma0-0 */ + dmas = <&main_udmap &pdma0 0 UDMA_DIR_TX>, + <&main_udmap &pdma0 0 UDMA_DIR_RX>; + dma-names = "tx", "rx"; +... +};
New binding document for Texas Instruments K3 NAVSS Unified DMA – Peripheral Root Complex (UDMA-P). UDMA-P is introduced as part of the K3 architecture and can be found on AM65x SoC. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> --- .../devicetree/bindings/dma/ti/k3-udma.txt | 134 ++++++++++++++++++ 1 file changed, 134 insertions(+) create mode 100644 Documentation/devicetree/bindings/dma/ti/k3-udma.txt