Re: [PATCH v2 13/14] ARM: DTS: am33xx: Use the new DT bindings for the eDMA3
On 12/04/2015 02:54 AM, Tony Lindgren wrote: > Hi Peter, > > * Peter Ujfalusi[151016 00:23]: > > I noticed something while changing dm81xx to use the edma_xbar.. > >> --- a/arch/arm/boot/dts/am33xx.dtsi >> +++ b/arch/arm/boot/dts/am33xx.dtsi >> + >> +edma_xbar: dma-router@44e10f90 { >> +compatible = "ti,am335x-edma-crossbar"; >> +reg = <0x44e10f90 0x40>; >> + >> +#dma-cells = <3>; >> +dma-requests = <32>; >> + >> +dma-masters = <>; >> }; > > The edma_xbar should now be just a child at offset 0xf90 under the > scm: scm@21. Can you please check the other patches too? Thanks Tony, I'll make sure they are in the correct place when resending them. -- Péter -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 13/14] ARM: DTS: am33xx: Use the new DT bindings for the eDMA3
Hi Peter, * Peter Ujfalusi[151016 00:23]: I noticed something while changing dm81xx to use the edma_xbar.. > --- a/arch/arm/boot/dts/am33xx.dtsi > +++ b/arch/arm/boot/dts/am33xx.dtsi > + > + edma_xbar: dma-router@44e10f90 { > + compatible = "ti,am335x-edma-crossbar"; > + reg = <0x44e10f90 0x40>; > + > + #dma-cells = <3>; > + dma-requests = <32>; > + > + dma-masters = <>; > }; The edma_xbar should now be just a child at offset 0xf90 under the scm: scm@21. Can you please check the other patches too? Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 13/14] ARM: DTS: am33xx: Use the new DT bindings for the eDMA3
On 11/04/2015 10:37 AM, Vinod Koul wrote: > On Mon, Nov 02, 2015 at 05:46:05PM +0200, Peter Ujfalusi wrote: >>> Okay I have reverted the two and applied the edma patch sent, can you please >>> verify topic/edma_fix before I merge it and send my PULL request. >> >> The branch looks good. Thank you! >> It would have been great if the DTS changes for am335x/am437x would have been >> in 4.4, but I will send them for 4.5 after rc1 is out. > > Any confirmation that this fixes the reported issue before I send pull > request? Patch 'dmaengine: edma: Add dummy driver skeleton for edma3-tptc' alone is fixing the issue: https://lkml.org/lkml/2015/11/2/297 I have tested it on: OMAP-L138-EVM, am335x-evmsk, am437x-gp-evm, dra7-evm (I have local patches to enable and use eDMA). All looks fine, mmc/audio works and they use eDMA. Olof: can you run a quick test with the linked patch? Thank you, Péter -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 13/14] ARM: DTS: am33xx: Use the new DT bindings for the eDMA3
On Mon, Nov 02, 2015 at 05:46:05PM +0200, Peter Ujfalusi wrote: > > Okay I have reverted the two and applied the edma patch sent, can you please > > verify topic/edma_fix before I merge it and send my PULL request. > > The branch looks good. Thank you! > It would have been great if the DTS changes for am335x/am437x would have been > in 4.4, but I will send them for 4.5 after rc1 is out. Any confirmation that this fixes the reported issue before I send pull request? -- ~Vinod -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 13/14] ARM: DTS: am33xx: Use the new DT bindings for the eDMA3
Vinod, On 11/02/2015 05:40 PM, Vinod Koul wrote: > On Mon, Nov 02, 2015 at 02:13:01PM +0200, Peter Ujfalusi wrote: >> Vinod, >> >> On 11/02/2015 12:04 PM, Vinod Koul wrote: >>> On Mon, Nov 02, 2015 at 01:21:19AM -0800, Olof Johansson wrote: Hi, 1) This seems to have broken BBB in -next for me, bisected down to this patch. For bootlog: http://arm-soc.lixom.net/bootlogs/next/next-20151102/bbb-arm-omap2plus_defconfig.html 2) Please avoid merging DT/platform code in your driver tree, Vinod, at least without an ack from the platform maintainer. It can be a a huge mess if they end up causing conflicts, so we always ask to merge the DT changes through the platform maintainer (Tony in this case) by default. >>> >>> I did warn when applying that I am doing so without ACK on ARM code, noone >>> said a thing! >>> >>> I knew Tony was following the work by Peter so assumed he must have been >>> okay >>> with it otherwise would have spoken for ~couple of weeks these were in >>> review >>> >>> Anyway now that we have a regression, I can revert this patch if that fixes, >>> please confirm, but might break edma... peter? >> >> Can you revert or drop the last two DTS patches? >> >> I think I will try a different route to get the split of the tpcc and tptc. >> Without the DT patches the driver will fall back to the legacy mode so things >> will work in a same way they did before. >> Or I can send a followup patch for edma.c, with that there is no need to add >> the HWMOD_INIT_NO_IDLE to hwmod and power management looks better. >> Basically I'm registering a 'dummy' driver for the edma3-tptc so omap hwmod >> code will not shut it down but we will keep the possibility to manage the >> power state still. > > Okay I have reverted the two and applied the edma patch sent, can you please > verify topic/edma_fix before I merge it and send my PULL request. The branch looks good. Thank you! It would have been great if the DTS changes for am335x/am437x would have been in 4.4, but I will send them for 4.5 after rc1 is out. > Would appreciate any tested-by > > Thanks > -- Péter -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 13/14] ARM: DTS: am33xx: Use the new DT bindings for the eDMA3
On Mon, Nov 02, 2015 at 02:13:01PM +0200, Peter Ujfalusi wrote: > Vinod, > > On 11/02/2015 12:04 PM, Vinod Koul wrote: > > On Mon, Nov 02, 2015 at 01:21:19AM -0800, Olof Johansson wrote: > >> Hi, > >> > >> 1) This seems to have broken BBB in -next for me, bisected down to this > >> patch. > >> > >> For bootlog: > >> http://arm-soc.lixom.net/bootlogs/next/next-20151102/bbb-arm-omap2plus_defconfig.html > >> > >> 2) Please avoid merging DT/platform code in your driver tree, Vinod, > >> at least without an ack from the platform maintainer. It can be a a > >> huge mess if they end up causing conflicts, so we always ask to merge > >> the DT changes through the platform maintainer (Tony in this case) by > >> default. > > > > I did warn when applying that I am doing so without ACK on ARM code, noone > > said a thing! > > > > I knew Tony was following the work by Peter so assumed he must have been > > okay > > with it otherwise would have spoken for ~couple of weeks these were in > > review > > > > Anyway now that we have a regression, I can revert this patch if that fixes, > > please confirm, but might break edma... peter? > > Can you revert or drop the last two DTS patches? > > I think I will try a different route to get the split of the tpcc and tptc. > Without the DT patches the driver will fall back to the legacy mode so things > will work in a same way they did before. > Or I can send a followup patch for edma.c, with that there is no need to add > the HWMOD_INIT_NO_IDLE to hwmod and power management looks better. > Basically I'm registering a 'dummy' driver for the edma3-tptc so omap hwmod > code will not shut it down but we will keep the possibility to manage the > power state still. Okay I have reverted the two and applied the edma patch sent, can you please verify topic/edma_fix before I merge it and send my PULL request. Would appreciate any tested-by Thanks -- ~Vinod -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 13/14] ARM: DTS: am33xx: Use the new DT bindings for the eDMA3
Hi, 1) This seems to have broken BBB in -next for me, bisected down to this patch. For bootlog: http://arm-soc.lixom.net/bootlogs/next/next-20151102/bbb-arm-omap2plus_defconfig.html 2) Please avoid merging DT/platform code in your driver tree, Vinod, at least without an ack from the platform maintainer. It can be a a huge mess if they end up causing conflicts, so we always ask to merge the DT changes through the platform maintainer (Tony in this case) by default. Thanks, -Olof On Fri, Oct 16, 2015 at 12:18 AM, Peter Ujfalusiwrote: > Switch to use the ti,edma3-tpcc and ti,edma3-tptc binding for the eDMA3 and > enable the DMA even crossbar with ti,am335x-edma-crossbar. > With the new bindings boards can customize and tweak the DMA channel > priority to match their needs. With the new binding the memcpy is safe > to be used since with the old binding it was not possible for a driver > to know which channel is allowed to be used as non HW triggered channel. > > Signed-off-by: Peter Ujfalusi > --- > arch/arm/boot/dts/am335x-evm.dts| 9 +--- > arch/arm/boot/dts/am335x-pepper.dts | 11 + > arch/arm/boot/dts/am33xx.dtsi | 96 > ++--- > 3 files changed, 73 insertions(+), 43 deletions(-) > > diff --git a/arch/arm/boot/dts/am335x-evm.dts > b/arch/arm/boot/dts/am335x-evm.dts > index 1942a5c8132d..507980672c32 100644 > --- a/arch/arm/boot/dts/am335x-evm.dts > +++ b/arch/arm/boot/dts/am335x-evm.dts > @@ -743,8 +743,8 @@ > { > /* these are on the crossbar and are outlined in the >xbar-event-map element */ > - dmas = < 12 > -13>; > + dmas = <_xbar 12 0 1 > + _xbar 13 0 2>; > dma-names = "tx", "rx"; > status = "okay"; > vmmc-supply = <_en_reg>; > @@ -766,11 +766,6 @@ > }; > }; > > - { > - ti,edma-xbar-event-map = /bits/ 16 <1 12 > - 2 13>; > -}; > - > { > status = "okay"; > }; > diff --git a/arch/arm/boot/dts/am335x-pepper.dts > b/arch/arm/boot/dts/am335x-pepper.dts > index 7106114c7464..39073b921664 100644 > --- a/arch/arm/boot/dts/am335x-pepper.dts > +++ b/arch/arm/boot/dts/am335x-pepper.dts > @@ -339,13 +339,6 @@ > ti,non-removable; > }; > > - { > - /* Map eDMA MMC2 Events from Crossbar */ > - ti,edma-xbar-event-map = /bits/ 16 <1 12 > -2 13>; > -}; > - > - > { > /* Wifi & Bluetooth on MMC #3 */ > status = "okay"; > @@ -354,8 +347,8 @@ > vmmmc-supply = <_reg>; > bus-width = <4>; > ti,non-removable; > - dmas = < 12 > -13>; > + dmas = <_xbar 12 0 1 > + _xbar 13 0 2>; > dma-names = "tx", "rx"; > }; > > diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi > index d23e2524d694..6053e75c6e99 100644 > --- a/arch/arm/boot/dts/am33xx.dtsi > +++ b/arch/arm/boot/dts/am33xx.dtsi > @@ -174,12 +174,54 @@ > }; > > edma: edma@4900 { > - compatible = "ti,edma3"; > - ti,hwmods = "tpcc", "tptc0", "tptc1", "tptc2"; > - reg = <0x4900 0x1>, > - <0x44e10f90 0x40>; > + compatible = "ti,edma3-tpcc"; > + ti,hwmods = "tpcc"; > + reg = <0x4900 0x1>; > + reg-names = "edma3_cc"; > interrupts = <12 13 14>; > - #dma-cells = <1>; > + interrupt-names = "edma3_ccint", "emda3_mperr", > + "edma3_ccerrint"; > + dma-requests = <64>; > + #dma-cells = <2>; > + > + ti,tptcs = <_tptc0 7>, <_tptc1 5>, > + <_tptc2 0>; > + > + ti,edma-memcpy-channels = /bits/ 16 <20 21>; > + }; > + > + edma_tptc0: tptc@4980 { > + compatible = "ti,edma3-tptc"; > + ti,hwmods = "tptc0"; > + reg = <0x4980 0x10>; > + interrupts = <112>; > + interrupt-names = "edma3_tcerrint"; > + }; > + > + edma_tptc1: tptc@4990 { > + compatible = "ti,edma3-tptc"; > + ti,hwmods = "tptc1"; > + reg = <0x4990 0x10>; > + interrupts = <113>; > + interrupt-names = "edma3_tcerrint"; > + }; > + > + edma_tptc2: tptc@49a0 { > + compatible = "ti,edma3-tptc"; > + ti,hwmods = "tptc2"; > + reg = <0x49a0 0x10>; > +
Re: [PATCH v2 13/14] ARM: DTS: am33xx: Use the new DT bindings for the eDMA3
On Mon, Nov 02, 2015 at 01:21:19AM -0800, Olof Johansson wrote: > Hi, > > 1) This seems to have broken BBB in -next for me, bisected down to this patch. > > For bootlog: > http://arm-soc.lixom.net/bootlogs/next/next-20151102/bbb-arm-omap2plus_defconfig.html > > 2) Please avoid merging DT/platform code in your driver tree, Vinod, > at least without an ack from the platform maintainer. It can be a a > huge mess if they end up causing conflicts, so we always ask to merge > the DT changes through the platform maintainer (Tony in this case) by > default. I did warn when applying that I am doing so without ACK on ARM code, noone said a thing! I knew Tony was following the work by Peter so assumed he must have been okay with it otherwise would have spoken for ~couple of weeks these were in review Anyway now that we have a regression, I can revert this patch if that fixes, please confirm, but might break edma... peter? -- ~Vinod -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 13/14] ARM: DTS: am33xx: Use the new DT bindings for the eDMA3
Hi Olof, On 11/02/2015 11:21 AM, Olof Johansson wrote: > Hi, > > 1) This seems to have broken BBB in -next for me, bisected down to this patch. > > For bootlog: > http://arm-soc.lixom.net/bootlogs/next/next-20151102/bbb-arm-omap2plus_defconfig.html Aargh, I had the patch which should have been included to the series (just sent it): https://www.mail-archive.com/linux-omap@vger.kernel.org/msg121134.html It was mixed with the patches I collected for 4.5, I don't know how this happened, but this is the reason I have not seen the issue you are seeing. > > 2) Please avoid merging DT/platform code in your driver tree, Vinod, > at least without an ack from the platform maintainer. It can be a a > huge mess if they end up causing conflicts, so we always ask to merge > the DT changes through the platform maintainer (Tony in this case) by > default. > > > Thanks, > > -Olof > > On Fri, Oct 16, 2015 at 12:18 AM, Peter Ujfalusi> wrote: >> Switch to use the ti,edma3-tpcc and ti,edma3-tptc binding for the eDMA3 and >> enable the DMA even crossbar with ti,am335x-edma-crossbar. >> With the new bindings boards can customize and tweak the DMA channel >> priority to match their needs. With the new binding the memcpy is safe >> to be used since with the old binding it was not possible for a driver >> to know which channel is allowed to be used as non HW triggered channel. >> >> Signed-off-by: Peter Ujfalusi >> --- >> arch/arm/boot/dts/am335x-evm.dts| 9 +--- >> arch/arm/boot/dts/am335x-pepper.dts | 11 + >> arch/arm/boot/dts/am33xx.dtsi | 96 >> ++--- >> 3 files changed, 73 insertions(+), 43 deletions(-) >> >> diff --git a/arch/arm/boot/dts/am335x-evm.dts >> b/arch/arm/boot/dts/am335x-evm.dts >> index 1942a5c8132d..507980672c32 100644 >> --- a/arch/arm/boot/dts/am335x-evm.dts >> +++ b/arch/arm/boot/dts/am335x-evm.dts >> @@ -743,8 +743,8 @@ >> { >> /* these are on the crossbar and are outlined in the >>xbar-event-map element */ >> - dmas = < 12 >> -13>; >> + dmas = <_xbar 12 0 1 >> + _xbar 13 0 2>; >> dma-names = "tx", "rx"; >> status = "okay"; >> vmmc-supply = <_en_reg>; >> @@ -766,11 +766,6 @@ >> }; >> }; >> >> - { >> - ti,edma-xbar-event-map = /bits/ 16 <1 12 >> - 2 13>; >> -}; >> - >> { >> status = "okay"; >> }; >> diff --git a/arch/arm/boot/dts/am335x-pepper.dts >> b/arch/arm/boot/dts/am335x-pepper.dts >> index 7106114c7464..39073b921664 100644 >> --- a/arch/arm/boot/dts/am335x-pepper.dts >> +++ b/arch/arm/boot/dts/am335x-pepper.dts >> @@ -339,13 +339,6 @@ >> ti,non-removable; >> }; >> >> - { >> - /* Map eDMA MMC2 Events from Crossbar */ >> - ti,edma-xbar-event-map = /bits/ 16 <1 12 >> -2 13>; >> -}; >> - >> - >> { >> /* Wifi & Bluetooth on MMC #3 */ >> status = "okay"; >> @@ -354,8 +347,8 @@ >> vmmmc-supply = <_reg>; >> bus-width = <4>; >> ti,non-removable; >> - dmas = < 12 >> -13>; >> + dmas = <_xbar 12 0 1 >> + _xbar 13 0 2>; >> dma-names = "tx", "rx"; >> }; >> >> diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi >> index d23e2524d694..6053e75c6e99 100644 >> --- a/arch/arm/boot/dts/am33xx.dtsi >> +++ b/arch/arm/boot/dts/am33xx.dtsi >> @@ -174,12 +174,54 @@ >> }; >> >> edma: edma@4900 { >> - compatible = "ti,edma3"; >> - ti,hwmods = "tpcc", "tptc0", "tptc1", "tptc2"; >> - reg = <0x4900 0x1>, >> - <0x44e10f90 0x40>; >> + compatible = "ti,edma3-tpcc"; >> + ti,hwmods = "tpcc"; >> + reg = <0x4900 0x1>; >> + reg-names = "edma3_cc"; >> interrupts = <12 13 14>; >> - #dma-cells = <1>; >> + interrupt-names = "edma3_ccint", "emda3_mperr", >> + "edma3_ccerrint"; >> + dma-requests = <64>; >> + #dma-cells = <2>; >> + >> + ti,tptcs = <_tptc0 7>, <_tptc1 5>, >> + <_tptc2 0>; >> + >> + ti,edma-memcpy-channels = /bits/ 16 <20 21>; >> + }; >> + >> + edma_tptc0: tptc@4980 { >> + compatible = "ti,edma3-tptc"; >> + ti,hwmods = "tptc0"; >> + reg = <0x4980 0x10>; >> + interrupts = <112>; >> + interrupt-names = "edma3_tcerrint"; >> + }; >> + >> + edma_tptc1:
Re: [PATCH v2 13/14] ARM: DTS: am33xx: Use the new DT bindings for the eDMA3
Vinod, On 11/02/2015 12:04 PM, Vinod Koul wrote: > On Mon, Nov 02, 2015 at 01:21:19AM -0800, Olof Johansson wrote: >> Hi, >> >> 1) This seems to have broken BBB in -next for me, bisected down to this >> patch. >> >> For bootlog: >> http://arm-soc.lixom.net/bootlogs/next/next-20151102/bbb-arm-omap2plus_defconfig.html >> >> 2) Please avoid merging DT/platform code in your driver tree, Vinod, >> at least without an ack from the platform maintainer. It can be a a >> huge mess if they end up causing conflicts, so we always ask to merge >> the DT changes through the platform maintainer (Tony in this case) by >> default. > > I did warn when applying that I am doing so without ACK on ARM code, noone > said a thing! > > I knew Tony was following the work by Peter so assumed he must have been okay > with it otherwise would have spoken for ~couple of weeks these were in > review > > Anyway now that we have a regression, I can revert this patch if that fixes, > please confirm, but might break edma... peter? Can you revert or drop the last two DTS patches? I think I will try a different route to get the split of the tpcc and tptc. Without the DT patches the driver will fall back to the legacy mode so things will work in a same way they did before. Or I can send a followup patch for edma.c, with that there is no need to add the HWMOD_INIT_NO_IDLE to hwmod and power management looks better. Basically I'm registering a 'dummy' driver for the edma3-tptc so omap hwmod code will not shut it down but we will keep the possibility to manage the power state still. -- Péter -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html