From: Peter Ujfalusi <peter.ujfalusi@ti.com> To: Rob Herring <robh@kernel.org> Cc: <nm@ti.com>, <devicetree@vger.kernel.org>, <grygorii.strashko@ti.com>, <lokeshvutla@ti.com>, <j-keerthy@ti.com>, <linux-kernel@vger.kernel.org>, <t-kristo@ti.com>, <tony@atomide.com>, <vkoul@kernel.org>, <ssantosh@kernel.org>, <dmaengine@vger.kernel.org>, <dan.j.williams@intel.com>, <linux-arm-kernel@lists.infradead.org> Subject: Re: [PATCH v3 07/14] dt-bindings: dma: ti: Add document for K3 UDMA Date: Tue, 15 Oct 2019 20:30:12 +0300 [thread overview] Message-ID: <d53f3bd7-d331-33c8-5232-c8f3cc9ac708@ti.com> (raw) In-Reply-To: <ef07299b-eb43-d582-adb8-46f46681f9a5@ti.com> Rob, On 10/11/19 10:30 AM, Peter Ujfalusi wrote: > > I have already moved the TR vs Packet mode channel selection, which does > make sense as it was Linux's choice to use TR for certain cases. > > If I move these to code then we need to have big tables > struct psil_config am654_psil[32767] = {}; > struct psil_config j721e_psil[32767] = {}; After thinking about this a bit more, I think we can move all the PSI-L endpoint configuration to the kernel as not all the 32767 threads are actually in use. Sure it is going to be some amount of static data in the kernel, but it is an acceptable compromise. The DMA binding can look like this: dmas = <&main_udmap 0xc400>, <&main_udmap 0x4400>; dma-names = "tx", "rx"; or dmas = <&main_udmap 0x4400 UDMA_DIR_TX>, <&main_udmap 0x4400 UDMA_DIR_RX>; dma-names = "tx", "rx"; If I keep the direction. 0xc400 is destination ID, which is 0x4400 | 0x8000 as per PSI-L specification. In the TRM only the source threads can be found as a map (thread IDs < 0x7fff), but the binding document can cover this. This way we don't need another dtsi file and I can create the map in the kernel. This will hide some details of the HW from DT, but since the PSI-L thread configuration is static in hardware I believe it is acceptable. However we still have uncovered features in the binding or in code, like a case when the RX does not have access to the DMA channel, only flows. Not sure if I should reserve the direction parameter as an indication to this or find other way. Basically we communicate on the given PSI-L thread without having a DMA channel as other core is owning the channel. What do you think? > > and for each new family member a new one. > > Also, if we want add DMA support for a new peripheral we would need to > modify the kernel and the DT in sync (well, kernel first, than DT). > >> Or do some combination of the above. > > What about this: > create a new dtsi file per SoC (k3-am654-psil.dtsi, k3-k721e-psil.dtsi) > for the PSI-L threads and inside something like this: > > psil-threads: psil-threads { > ... > /* SA2UL: 0x4000 - 0x4003 */ > ti,psil-config-4000 { > linux,udma-mode = <UDMA_PKT_MODE>; > ti,needs-epib; > ti,psd-size = <64>; > ti,notdpkt; > }; > > ti,psil-config-4001 { > linux,udma-mode = <UDMA_PKT_MODE>; > ti,needs-epib; > ti,psd-size = <64>; > ti,notdpkt; > }; > > ti,psil-config-4002 { > linux,udma-mode = <UDMA_PKT_MODE>; > ti,needs-epib; > ti,psd-size = <64>; > ti,notdpkt; > }; > > ... > /* PDMA6 (PDMA_MCASP_G0): 0x4400 - 0x4402 */ > thread-4400 { > ti,pdma-statictr-type = <PDMA_STATIC_TR_XY>; > ti,pdma-enable-acc32; > ti,pdma-enable-burst; > }; > > thread-4401 { > ti,pdma-statictr-type = <PDMA_STATIC_TR_XY>; > ti,pdma-enable-acc32; > ti,pdma-enable-burst; > }; > > thread-4402 { > ti,pdma-statictr-type = <PDMA_STATIC_TR_XY>; > ti,pdma-enable-acc32; > ti,pdma-enable-burst; > }; > > ... > }; > > Then the binding would look like this for sa2ul: > > /* tx: crypto_pnp-1, rx: crypto_pnp-1 */ > dmas = <&main_udmap 0x4000 UDMA_DIR_TX>, > <&main_udmap 0x4000 UDMA_DIR_RX>, > <&main_udmap 0x4001 UDMA_DIR_RX>; > dma-names = "tx", "rx1", "rx2"; > > for McASP: > dmas = <&main_udmap 0x4400 UDMA_DIR_TX>, > <&main_udmap 0x4400 UDMA_DIR_RX>; > dma-names = "tx", "rx"; > > Then either we can have phandle in the udmap nodes to the psil-threads, > or just find it from the root when needed. > >> Sorry I don't have specific suggestions, but I just see lots of properties >> and complexity, and I don't really understand the h/w here. Putting the >> complexity in what is an ABI is generally not a good plan. > > The complexity is coming from the hardware itself. If I can not describe > the hardware than it is not going to be easy for the software to figure > out what it is dealing with. > >> And I don't >> have the bandwidth to study and understand the complexities of your h/w >> (and everyone elses), so just more explanations are not likely to really >> help. > > Sure, I understand. > > - Péter > > Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. > Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki > > _______________________________________________ > linux-arm-kernel mailing list > linux-arm-kernel@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel > - Peter Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
WARNING: multiple messages have this Message-ID (diff)
From: Peter Ujfalusi <peter.ujfalusi@ti.com> To: Rob Herring <robh@kernel.org> Cc: nm@ti.com, devicetree@vger.kernel.org, grygorii.strashko@ti.com, lokeshvutla@ti.com, j-keerthy@ti.com, linux-kernel@vger.kernel.org, t-kristo@ti.com, tony@atomide.com, vkoul@kernel.org, ssantosh@kernel.org, dmaengine@vger.kernel.org, dan.j.williams@intel.com, linux-arm-kernel@lists.infradead.org Subject: Re: [PATCH v3 07/14] dt-bindings: dma: ti: Add document for K3 UDMA Date: Tue, 15 Oct 2019 20:30:12 +0300 [thread overview] Message-ID: <d53f3bd7-d331-33c8-5232-c8f3cc9ac708@ti.com> (raw) In-Reply-To: <ef07299b-eb43-d582-adb8-46f46681f9a5@ti.com> Rob, On 10/11/19 10:30 AM, Peter Ujfalusi wrote: > > I have already moved the TR vs Packet mode channel selection, which does > make sense as it was Linux's choice to use TR for certain cases. > > If I move these to code then we need to have big tables > struct psil_config am654_psil[32767] = {}; > struct psil_config j721e_psil[32767] = {}; After thinking about this a bit more, I think we can move all the PSI-L endpoint configuration to the kernel as not all the 32767 threads are actually in use. Sure it is going to be some amount of static data in the kernel, but it is an acceptable compromise. The DMA binding can look like this: dmas = <&main_udmap 0xc400>, <&main_udmap 0x4400>; dma-names = "tx", "rx"; or dmas = <&main_udmap 0x4400 UDMA_DIR_TX>, <&main_udmap 0x4400 UDMA_DIR_RX>; dma-names = "tx", "rx"; If I keep the direction. 0xc400 is destination ID, which is 0x4400 | 0x8000 as per PSI-L specification. In the TRM only the source threads can be found as a map (thread IDs < 0x7fff), but the binding document can cover this. This way we don't need another dtsi file and I can create the map in the kernel. This will hide some details of the HW from DT, but since the PSI-L thread configuration is static in hardware I believe it is acceptable. However we still have uncovered features in the binding or in code, like a case when the RX does not have access to the DMA channel, only flows. Not sure if I should reserve the direction parameter as an indication to this or find other way. Basically we communicate on the given PSI-L thread without having a DMA channel as other core is owning the channel. What do you think? > > and for each new family member a new one. > > Also, if we want add DMA support for a new peripheral we would need to > modify the kernel and the DT in sync (well, kernel first, than DT). > >> Or do some combination of the above. > > What about this: > create a new dtsi file per SoC (k3-am654-psil.dtsi, k3-k721e-psil.dtsi) > for the PSI-L threads and inside something like this: > > psil-threads: psil-threads { > ... > /* SA2UL: 0x4000 - 0x4003 */ > ti,psil-config-4000 { > linux,udma-mode = <UDMA_PKT_MODE>; > ti,needs-epib; > ti,psd-size = <64>; > ti,notdpkt; > }; > > ti,psil-config-4001 { > linux,udma-mode = <UDMA_PKT_MODE>; > ti,needs-epib; > ti,psd-size = <64>; > ti,notdpkt; > }; > > ti,psil-config-4002 { > linux,udma-mode = <UDMA_PKT_MODE>; > ti,needs-epib; > ti,psd-size = <64>; > ti,notdpkt; > }; > > ... > /* PDMA6 (PDMA_MCASP_G0): 0x4400 - 0x4402 */ > thread-4400 { > ti,pdma-statictr-type = <PDMA_STATIC_TR_XY>; > ti,pdma-enable-acc32; > ti,pdma-enable-burst; > }; > > thread-4401 { > ti,pdma-statictr-type = <PDMA_STATIC_TR_XY>; > ti,pdma-enable-acc32; > ti,pdma-enable-burst; > }; > > thread-4402 { > ti,pdma-statictr-type = <PDMA_STATIC_TR_XY>; > ti,pdma-enable-acc32; > ti,pdma-enable-burst; > }; > > ... > }; > > Then the binding would look like this for sa2ul: > > /* tx: crypto_pnp-1, rx: crypto_pnp-1 */ > dmas = <&main_udmap 0x4000 UDMA_DIR_TX>, > <&main_udmap 0x4000 UDMA_DIR_RX>, > <&main_udmap 0x4001 UDMA_DIR_RX>; > dma-names = "tx", "rx1", "rx2"; > > for McASP: > dmas = <&main_udmap 0x4400 UDMA_DIR_TX>, > <&main_udmap 0x4400 UDMA_DIR_RX>; > dma-names = "tx", "rx"; > > Then either we can have phandle in the udmap nodes to the psil-threads, > or just find it from the root when needed. > >> Sorry I don't have specific suggestions, but I just see lots of properties >> and complexity, and I don't really understand the h/w here. Putting the >> complexity in what is an ABI is generally not a good plan. > > The complexity is coming from the hardware itself. If I can not describe > the hardware than it is not going to be easy for the software to figure > out what it is dealing with. > >> And I don't >> have the bandwidth to study and understand the complexities of your h/w >> (and everyone elses), so just more explanations are not likely to really >> help. > > Sure, I understand. > > - Péter > > Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. > Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki > > _______________________________________________ > linux-arm-kernel mailing list > linux-arm-kernel@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel > - Peter Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2019-10-15 17:29 UTC|newest] Thread overview: 94+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-10-01 6:16 [PATCH v3 00/14] dmaengine/soc: Add Texas Instruments UDMA support Peter Ujfalusi 2019-10-01 6:16 ` Peter Ujfalusi 2019-10-01 6:16 ` Peter Ujfalusi 2019-10-01 6:16 ` [PATCH v3 01/14] bindings: soc: ti: add documentation for k3 ringacc Peter Ujfalusi 2019-10-01 6:16 ` Peter Ujfalusi 2019-10-01 6:16 ` Peter Ujfalusi 2019-10-01 6:16 ` [PATCH v3 02/14] soc: ti: k3: add navss ringacc driver Peter Ujfalusi 2019-10-01 6:16 ` Peter Ujfalusi 2019-10-01 6:16 ` Peter Ujfalusi 2019-10-09 7:14 ` Tero Kristo 2019-10-09 7:14 ` Tero Kristo 2019-10-09 7:14 ` Tero Kristo 2019-10-09 13:27 ` Lokesh Vutla 2019-10-09 13:27 ` Lokesh Vutla 2019-10-09 13:27 ` Lokesh Vutla 2019-10-25 9:30 ` Peter Ujfalusi 2019-10-25 9:30 ` Peter Ujfalusi 2019-10-29 8:52 ` Lokesh Vutla 2019-10-29 8:52 ` Lokesh Vutla 2019-10-30 13:10 ` Grygorii Strashko 2019-10-30 13:10 ` Grygorii Strashko 2019-10-01 6:16 ` [PATCH v3 03/14] dmaengine: doc: Add sections for per descriptor metadata support Peter Ujfalusi 2019-10-01 6:16 ` Peter Ujfalusi 2019-10-01 6:16 ` Peter Ujfalusi 2019-10-09 7:30 ` Tero Kristo 2019-10-09 7:30 ` Tero Kristo 2019-10-09 7:30 ` Tero Kristo 2019-10-01 6:16 ` [PATCH v3 04/14] dmaengine: Add metadata_ops for dma_async_tx_descriptor Peter Ujfalusi 2019-10-01 6:16 ` Peter Ujfalusi 2019-10-01 6:16 ` Peter Ujfalusi 2019-10-09 7:37 ` Tero Kristo 2019-10-09 7:37 ` Tero Kristo 2019-10-09 7:37 ` Tero Kristo 2019-10-01 6:16 ` [PATCH v3 05/14] dmaengine: Add support for reporting DMA cached data amount Peter Ujfalusi 2019-10-01 6:16 ` Peter Ujfalusi 2019-10-01 6:16 ` Peter Ujfalusi 2019-10-09 9:17 ` Tero Kristo 2019-10-09 9:17 ` Tero Kristo 2019-10-09 9:17 ` Tero Kristo 2019-10-01 6:16 ` [PATCH v3 06/14] dmaengine: ti: Add cppi5 header for UDMA Peter Ujfalusi 2019-10-01 6:16 ` Peter Ujfalusi 2019-10-01 6:16 ` Peter Ujfalusi 2019-10-09 9:13 ` Tero Kristo 2019-10-09 9:13 ` Tero Kristo 2019-10-09 9:13 ` Tero Kristo 2019-10-01 6:16 ` [PATCH v3 07/14] dt-bindings: dma: ti: Add document for K3 UDMA Peter Ujfalusi 2019-10-01 6:16 ` Peter Ujfalusi 2019-10-01 6:16 ` Peter Ujfalusi 2019-10-10 17:52 ` Rob Herring 2019-10-10 17:52 ` Rob Herring 2019-10-11 7:30 ` Peter Ujfalusi 2019-10-11 7:30 ` Peter Ujfalusi 2019-10-15 17:30 ` Peter Ujfalusi [this message] 2019-10-15 17:30 ` Peter Ujfalusi 2019-10-17 14:03 ` Rob Herring 2019-10-17 14:03 ` Rob Herring 2019-10-22 11:46 ` Peter Ujfalusi 2019-10-22 11:46 ` Peter Ujfalusi 2019-10-01 6:16 ` [PATCH v3 08/14] dmaengine: ti: New driver for K3 UDMA - split#1: defines, structs, io func Peter Ujfalusi 2019-10-01 6:16 ` Peter Ujfalusi 2019-10-01 6:16 ` Peter Ujfalusi 2019-10-09 13:40 ` Tero Kristo 2019-10-09 13:40 ` Tero Kristo 2019-10-09 13:40 ` Tero Kristo 2019-10-01 6:16 ` [PATCH v3 09/14] dmaengine: ti: New driver for K3 UDMA - split#2: probe/remove, xlate and filter_fn Peter Ujfalusi 2019-10-01 6:16 ` Peter Ujfalusi 2019-10-01 6:16 ` Peter Ujfalusi 2019-10-03 8:35 ` Peter Ujfalusi 2019-10-03 8:35 ` Peter Ujfalusi 2019-10-03 8:35 ` Peter Ujfalusi 2019-10-01 6:17 ` [PATCH v3 10/14] dmaengine: ti: New driver for K3 UDMA - split#3: alloc/free chan_resources Peter Ujfalusi 2019-10-01 6:17 ` Peter Ujfalusi 2019-10-01 6:17 ` Peter Ujfalusi 2019-10-01 6:17 ` [PATCH v3 11/14] dmaengine: ti: New driver for K3 UDMA - split#4: dma_device callbacks 1 Peter Ujfalusi 2019-10-01 6:17 ` Peter Ujfalusi 2019-10-01 6:17 ` Peter Ujfalusi 2019-10-01 6:17 ` [PATCH v3 12/14] dmaengine: ti: New driver for K3 UDMA - split#5: dma_device callbacks 2 Peter Ujfalusi 2019-10-01 6:17 ` Peter Ujfalusi 2019-10-01 6:17 ` Peter Ujfalusi 2019-10-01 6:17 ` [PATCH v3 13/14] dmaengine: ti: New driver for K3 UDMA - split#6: Kconfig and Makefile Peter Ujfalusi 2019-10-01 6:17 ` Peter Ujfalusi 2019-10-01 6:17 ` Peter Ujfalusi 2019-10-01 6:17 ` [PATCH v3 14/14] dmaengine: ti: k3-udma: Add glue layer for non DMAengine users Peter Ujfalusi 2019-10-01 6:17 ` Peter Ujfalusi 2019-10-01 6:17 ` Peter Ujfalusi 2019-10-04 16:35 ` [PATCH v3 00/14] dmaengine/soc: Add Texas Instruments UDMA support santosh.shilimkar 2019-10-04 16:35 ` santosh.shilimkar 2019-10-04 16:35 ` santosh.shilimkar 2019-10-08 10:09 ` Peter Ujfalusi 2019-10-08 10:09 ` Peter Ujfalusi 2019-10-08 10:09 ` Peter Ujfalusi 2019-10-09 16:02 ` santosh.shilimkar 2019-10-09 16:02 ` santosh.shilimkar 2019-10-09 16:02 ` santosh.shilimkar
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=d53f3bd7-d331-33c8-5232-c8f3cc9ac708@ti.com \ --to=peter.ujfalusi@ti.com \ --cc=dan.j.williams@intel.com \ --cc=devicetree@vger.kernel.org \ --cc=dmaengine@vger.kernel.org \ --cc=grygorii.strashko@ti.com \ --cc=j-keerthy@ti.com \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=lokeshvutla@ti.com \ --cc=nm@ti.com \ --cc=robh@kernel.org \ --cc=ssantosh@kernel.org \ --cc=t-kristo@ti.com \ --cc=tony@atomide.com \ --cc=vkoul@kernel.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.