Re: [PATCH v2 13/14] ARM: DTS: am33xx: Use the new DT bindings for the eDMA3

2015-12-04 Thread Peter Ujfalusi
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

2015-12-03 Thread Tony Lindgren
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

2015-11-04 Thread Peter Ujfalusi
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

2015-11-04 Thread Vinod Koul
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

2015-11-02 Thread Peter Ujfalusi
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

2015-11-02 Thread Vinod Koul
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

2015-11-02 Thread Olof Johansson
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 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: 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

2015-11-02 Thread Vinod Koul
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

2015-11-02 Thread Peter Ujfalusi
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

2015-11-02 Thread Peter Ujfalusi
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