All of lore.kernel.org
 help / color / mirror / Atom feed
From: nsekhar@ti.com (Sekhar Nori)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 2/6] ARM: DTS: da850: Use the new DT bindings for the eDMA3
Date: Tue, 15 Dec 2015 19:18:55 +0530	[thread overview]
Message-ID: <56701A47.9090105@ti.com> (raw)
In-Reply-To: <566FFD1C.4080000@ti.com>

On Tuesday 15 December 2015 05:14 PM, Peter Ujfalusi wrote:
> On 12/15/2015 11:38 AM, Sekhar Nori wrote:
>> Hi Peter,
>>
>> On Friday 04 December 2015 07:23 PM, Peter Ujfalusi wrote:
>>> Switch to use the ti,edma3-tpcc and ti,edma3-tptc binding for the eDMA3.
>>> 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.
>>> Using the new binding will allow us to reserve PaRAM slots to be used by
>>> the DSP which was not possible before and prevented the da850 boards to be
>>> moved to DT only.
>>>
>>> Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
>>> ---
>>>  arch/arm/boot/dts/da850-enbw-cmc.dts |  5 +++++
>>>  arch/arm/boot/dts/da850-evm.dts      |  5 +++++
>>>  arch/arm/boot/dts/da850.dtsi         | 27 ++++++++++++++++++++++-----
>>>  3 files changed, 32 insertions(+), 5 deletions(-)
>>>
>>> diff --git a/arch/arm/boot/dts/da850-enbw-cmc.dts b/arch/arm/boot/dts/da850-enbw-cmc.dts
>>> index e750ab9086d5..ca9117624cf9 100644
>>> --- a/arch/arm/boot/dts/da850-enbw-cmc.dts
>>> +++ b/arch/arm/boot/dts/da850-enbw-cmc.dts
>>> @@ -28,3 +28,8 @@
>>>  		};
>>>  	};
>>>  };
>>> +
>>> +&edma0 {
>>> +	ti,edma-reserved-slot-ranges = /bits/ 16 <32 50>;
>>> +	ti,edma-memcpy-channels = /bits/ 16 <20 21>;
>>> +};
>>> diff --git a/arch/arm/boot/dts/da850-evm.dts b/arch/arm/boot/dts/da850-evm.dts
>>> index d807285a61cd..33467feb272a 100644
>>> --- a/arch/arm/boot/dts/da850-evm.dts
>>> +++ b/arch/arm/boot/dts/da850-evm.dts
>>> @@ -243,3 +243,8 @@
>>>  	tx-num-evt = <32>;
>>>  	rx-num-evt = <32>;
>>>  };
>>> +
>>> +&edma0 {
>>> +	ti,edma-reserved-slot-ranges = /bits/ 16 <32 50>;
>>> +	ti,edma-memcpy-channels = /bits/ 16 <20 21>;
>>
>> These correspond to PRU events. It is true that most likely they will
>> never be used for peripheral DMA and can be dedicated as memcpy
>> channels. However, since this is being encoded in DT, we need to be sure
>> that they will never be used for peripheral DMA on this board.
>>
>> So, I would prefer if you do not reserve any channels for memcpy until
>> there is a real need/usecase for them. I know the board file has these
>> reserved but board file could be updated as you liked. With DT we need
>> to maintain backward compatibility. So I would rather do it when there
>> is an actual need for it.
> 
> If we do not reserve channels for memcpy then you will have no support for
> memcpy on these boards. Not sure if we use memcpy in any of our drivers in
> daVinci, so it might be just fine to not have DMA memcpy support at all.

Not that I know of. No driver uses DMA memcpy

> But how about using edma1's reserved channels as memcpy (19-23, 30-31)? I

I think this is much more reasonable.

> don't know which channels the DSP would use on these boards, so it is never
> going to be safe from that point.

Yeah, and thats why I think its better to add it as and when there is a
real need for it. At least at that point we are sure of the usecase.

> 
>> In future, if/when we gain QDMA support, the QDMA channels could be used
>> for memcopy.
> 
> Well, in short there is no way to get the qDMA working in a different way
> either. qDMA channel is in essence using 'normal' eDMA channel. This means
> that we still need to reserve the eDMA channel to be used for memcpy, but
> instead of SW triggering it (as we do it right now), we would need to use the
> channel as qDMA and set things up accordingly. I don't really see the benefit
> for qDMA mode to be honest.

I guess the only advantage is that they will not clash with peripheral
mode usage. But even then, some sort of reservation is needed. So I
guess QDMA is no better than the EDMA reserved channels?

>>
>>> +};
>>> diff --git a/arch/arm/boot/dts/da850.dtsi b/arch/arm/boot/dts/da850.dtsi
>>> index e73f5efb3aa3..9e46eb51a8da 100644
>>> --- a/arch/arm/boot/dts/da850.dtsi
>>> +++ b/arch/arm/boot/dts/da850.dtsi
>>> @@ -151,11 +151,28 @@
>>>  
>>>  		};
>>>  		edma0: edma at 01c00000 {
>>> -			compatible = "ti,edma3";
>>> +			compatible = "ti,edma3-tpcc";
>>>  			/* eDMA3 CC0: 0x01c0 0000 - 0x01c0 7fff */
>>>  			reg =	<0x0 0x8000>;
>>> -			interrupts = <11 13 12>;
>>> -			#dma-cells = <1>;
>>> +			reg-names = "edma3_cc";
>>> +			interrupts = <11 12>;
>>> +			interrupt-names = "edma3_ccint", "edma3_ccerrint";
>>> +			#dma-cells = <2>;
>>> +
>>> +			ti,tptcs = <&edma0_tptc0 7>, <&edma0_tptc1 0>;
>>> +			ti,edma-memcpy-channels = /bits/ 16 <20 21>;
>>
>> Same here. I would drop this.
> 
> OK, I'll drop this part.

For now, I think its better to not add any reservation. It can be added
when its really needed.

Thanks,
Sekhar

WARNING: multiple messages have this Message-ID (diff)
From: Sekhar Nori <nsekhar@ti.com>
To: Peter Ujfalusi <peter.ujfalusi@ti.com>
Cc: linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org,
	linux-kernel@vger.kernel.org, khilman@deeprootsystems.com
Subject: Re: [PATCH 2/6] ARM: DTS: da850: Use the new DT bindings for the eDMA3
Date: Tue, 15 Dec 2015 19:18:55 +0530	[thread overview]
Message-ID: <56701A47.9090105@ti.com> (raw)
In-Reply-To: <566FFD1C.4080000@ti.com>

On Tuesday 15 December 2015 05:14 PM, Peter Ujfalusi wrote:
> On 12/15/2015 11:38 AM, Sekhar Nori wrote:
>> Hi Peter,
>>
>> On Friday 04 December 2015 07:23 PM, Peter Ujfalusi wrote:
>>> Switch to use the ti,edma3-tpcc and ti,edma3-tptc binding for the eDMA3.
>>> 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.
>>> Using the new binding will allow us to reserve PaRAM slots to be used by
>>> the DSP which was not possible before and prevented the da850 boards to be
>>> moved to DT only.
>>>
>>> Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
>>> ---
>>>  arch/arm/boot/dts/da850-enbw-cmc.dts |  5 +++++
>>>  arch/arm/boot/dts/da850-evm.dts      |  5 +++++
>>>  arch/arm/boot/dts/da850.dtsi         | 27 ++++++++++++++++++++++-----
>>>  3 files changed, 32 insertions(+), 5 deletions(-)
>>>
>>> diff --git a/arch/arm/boot/dts/da850-enbw-cmc.dts b/arch/arm/boot/dts/da850-enbw-cmc.dts
>>> index e750ab9086d5..ca9117624cf9 100644
>>> --- a/arch/arm/boot/dts/da850-enbw-cmc.dts
>>> +++ b/arch/arm/boot/dts/da850-enbw-cmc.dts
>>> @@ -28,3 +28,8 @@
>>>  		};
>>>  	};
>>>  };
>>> +
>>> +&edma0 {
>>> +	ti,edma-reserved-slot-ranges = /bits/ 16 <32 50>;
>>> +	ti,edma-memcpy-channels = /bits/ 16 <20 21>;
>>> +};
>>> diff --git a/arch/arm/boot/dts/da850-evm.dts b/arch/arm/boot/dts/da850-evm.dts
>>> index d807285a61cd..33467feb272a 100644
>>> --- a/arch/arm/boot/dts/da850-evm.dts
>>> +++ b/arch/arm/boot/dts/da850-evm.dts
>>> @@ -243,3 +243,8 @@
>>>  	tx-num-evt = <32>;
>>>  	rx-num-evt = <32>;
>>>  };
>>> +
>>> +&edma0 {
>>> +	ti,edma-reserved-slot-ranges = /bits/ 16 <32 50>;
>>> +	ti,edma-memcpy-channels = /bits/ 16 <20 21>;
>>
>> These correspond to PRU events. It is true that most likely they will
>> never be used for peripheral DMA and can be dedicated as memcpy
>> channels. However, since this is being encoded in DT, we need to be sure
>> that they will never be used for peripheral DMA on this board.
>>
>> So, I would prefer if you do not reserve any channels for memcpy until
>> there is a real need/usecase for them. I know the board file has these
>> reserved but board file could be updated as you liked. With DT we need
>> to maintain backward compatibility. So I would rather do it when there
>> is an actual need for it.
> 
> If we do not reserve channels for memcpy then you will have no support for
> memcpy on these boards. Not sure if we use memcpy in any of our drivers in
> daVinci, so it might be just fine to not have DMA memcpy support at all.

Not that I know of. No driver uses DMA memcpy

> But how about using edma1's reserved channels as memcpy (19-23, 30-31)? I

I think this is much more reasonable.

> don't know which channels the DSP would use on these boards, so it is never
> going to be safe from that point.

Yeah, and thats why I think its better to add it as and when there is a
real need for it. At least at that point we are sure of the usecase.

> 
>> In future, if/when we gain QDMA support, the QDMA channels could be used
>> for memcopy.
> 
> Well, in short there is no way to get the qDMA working in a different way
> either. qDMA channel is in essence using 'normal' eDMA channel. This means
> that we still need to reserve the eDMA channel to be used for memcpy, but
> instead of SW triggering it (as we do it right now), we would need to use the
> channel as qDMA and set things up accordingly. I don't really see the benefit
> for qDMA mode to be honest.

I guess the only advantage is that they will not clash with peripheral
mode usage. But even then, some sort of reservation is needed. So I
guess QDMA is no better than the EDMA reserved channels?

>>
>>> +};
>>> diff --git a/arch/arm/boot/dts/da850.dtsi b/arch/arm/boot/dts/da850.dtsi
>>> index e73f5efb3aa3..9e46eb51a8da 100644
>>> --- a/arch/arm/boot/dts/da850.dtsi
>>> +++ b/arch/arm/boot/dts/da850.dtsi
>>> @@ -151,11 +151,28 @@
>>>  
>>>  		};
>>>  		edma0: edma@01c00000 {
>>> -			compatible = "ti,edma3";
>>> +			compatible = "ti,edma3-tpcc";
>>>  			/* eDMA3 CC0: 0x01c0 0000 - 0x01c0 7fff */
>>>  			reg =	<0x0 0x8000>;
>>> -			interrupts = <11 13 12>;
>>> -			#dma-cells = <1>;
>>> +			reg-names = "edma3_cc";
>>> +			interrupts = <11 12>;
>>> +			interrupt-names = "edma3_ccint", "edma3_ccerrint";
>>> +			#dma-cells = <2>;
>>> +
>>> +			ti,tptcs = <&edma0_tptc0 7>, <&edma0_tptc1 0>;
>>> +			ti,edma-memcpy-channels = /bits/ 16 <20 21>;
>>
>> Same here. I would drop this.
> 
> OK, I'll drop this part.

For now, I think its better to not add any reservation. It can be added
when its really needed.

Thanks,
Sekhar

WARNING: multiple messages have this Message-ID (diff)
From: Sekhar Nori <nsekhar@ti.com>
To: Peter Ujfalusi <peter.ujfalusi@ti.com>
Cc: <linux-arm-kernel@lists.infradead.org>,
	<devicetree@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
	<khilman@deeprootsystems.com>
Subject: Re: [PATCH 2/6] ARM: DTS: da850: Use the new DT bindings for the eDMA3
Date: Tue, 15 Dec 2015 19:18:55 +0530	[thread overview]
Message-ID: <56701A47.9090105@ti.com> (raw)
In-Reply-To: <566FFD1C.4080000@ti.com>

On Tuesday 15 December 2015 05:14 PM, Peter Ujfalusi wrote:
> On 12/15/2015 11:38 AM, Sekhar Nori wrote:
>> Hi Peter,
>>
>> On Friday 04 December 2015 07:23 PM, Peter Ujfalusi wrote:
>>> Switch to use the ti,edma3-tpcc and ti,edma3-tptc binding for the eDMA3.
>>> 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.
>>> Using the new binding will allow us to reserve PaRAM slots to be used by
>>> the DSP which was not possible before and prevented the da850 boards to be
>>> moved to DT only.
>>>
>>> Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
>>> ---
>>>  arch/arm/boot/dts/da850-enbw-cmc.dts |  5 +++++
>>>  arch/arm/boot/dts/da850-evm.dts      |  5 +++++
>>>  arch/arm/boot/dts/da850.dtsi         | 27 ++++++++++++++++++++++-----
>>>  3 files changed, 32 insertions(+), 5 deletions(-)
>>>
>>> diff --git a/arch/arm/boot/dts/da850-enbw-cmc.dts b/arch/arm/boot/dts/da850-enbw-cmc.dts
>>> index e750ab9086d5..ca9117624cf9 100644
>>> --- a/arch/arm/boot/dts/da850-enbw-cmc.dts
>>> +++ b/arch/arm/boot/dts/da850-enbw-cmc.dts
>>> @@ -28,3 +28,8 @@
>>>  		};
>>>  	};
>>>  };
>>> +
>>> +&edma0 {
>>> +	ti,edma-reserved-slot-ranges = /bits/ 16 <32 50>;
>>> +	ti,edma-memcpy-channels = /bits/ 16 <20 21>;
>>> +};
>>> diff --git a/arch/arm/boot/dts/da850-evm.dts b/arch/arm/boot/dts/da850-evm.dts
>>> index d807285a61cd..33467feb272a 100644
>>> --- a/arch/arm/boot/dts/da850-evm.dts
>>> +++ b/arch/arm/boot/dts/da850-evm.dts
>>> @@ -243,3 +243,8 @@
>>>  	tx-num-evt = <32>;
>>>  	rx-num-evt = <32>;
>>>  };
>>> +
>>> +&edma0 {
>>> +	ti,edma-reserved-slot-ranges = /bits/ 16 <32 50>;
>>> +	ti,edma-memcpy-channels = /bits/ 16 <20 21>;
>>
>> These correspond to PRU events. It is true that most likely they will
>> never be used for peripheral DMA and can be dedicated as memcpy
>> channels. However, since this is being encoded in DT, we need to be sure
>> that they will never be used for peripheral DMA on this board.
>>
>> So, I would prefer if you do not reserve any channels for memcpy until
>> there is a real need/usecase for them. I know the board file has these
>> reserved but board file could be updated as you liked. With DT we need
>> to maintain backward compatibility. So I would rather do it when there
>> is an actual need for it.
> 
> If we do not reserve channels for memcpy then you will have no support for
> memcpy on these boards. Not sure if we use memcpy in any of our drivers in
> daVinci, so it might be just fine to not have DMA memcpy support at all.

Not that I know of. No driver uses DMA memcpy

> But how about using edma1's reserved channels as memcpy (19-23, 30-31)? I

I think this is much more reasonable.

> don't know which channels the DSP would use on these boards, so it is never
> going to be safe from that point.

Yeah, and thats why I think its better to add it as and when there is a
real need for it. At least at that point we are sure of the usecase.

> 
>> In future, if/when we gain QDMA support, the QDMA channels could be used
>> for memcopy.
> 
> Well, in short there is no way to get the qDMA working in a different way
> either. qDMA channel is in essence using 'normal' eDMA channel. This means
> that we still need to reserve the eDMA channel to be used for memcpy, but
> instead of SW triggering it (as we do it right now), we would need to use the
> channel as qDMA and set things up accordingly. I don't really see the benefit
> for qDMA mode to be honest.

I guess the only advantage is that they will not clash with peripheral
mode usage. But even then, some sort of reservation is needed. So I
guess QDMA is no better than the EDMA reserved channels?

>>
>>> +};
>>> diff --git a/arch/arm/boot/dts/da850.dtsi b/arch/arm/boot/dts/da850.dtsi
>>> index e73f5efb3aa3..9e46eb51a8da 100644
>>> --- a/arch/arm/boot/dts/da850.dtsi
>>> +++ b/arch/arm/boot/dts/da850.dtsi
>>> @@ -151,11 +151,28 @@
>>>  
>>>  		};
>>>  		edma0: edma@01c00000 {
>>> -			compatible = "ti,edma3";
>>> +			compatible = "ti,edma3-tpcc";
>>>  			/* eDMA3 CC0: 0x01c0 0000 - 0x01c0 7fff */
>>>  			reg =	<0x0 0x8000>;
>>> -			interrupts = <11 13 12>;
>>> -			#dma-cells = <1>;
>>> +			reg-names = "edma3_cc";
>>> +			interrupts = <11 12>;
>>> +			interrupt-names = "edma3_ccint", "edma3_ccerrint";
>>> +			#dma-cells = <2>;
>>> +
>>> +			ti,tptcs = <&edma0_tptc0 7>, <&edma0_tptc1 0>;
>>> +			ti,edma-memcpy-channels = /bits/ 16 <20 21>;
>>
>> Same here. I would drop this.
> 
> OK, I'll drop this part.

For now, I think its better to not add any reservation. It can be added
when its really needed.

Thanks,
Sekhar

  reply	other threads:[~2015-12-15 13:48 UTC|newest]

Thread overview: 45+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-12-04 13:53 [PATCH 0/6] ARM: DTS: da850: eDMA new bindings and MMC/SPI DMA support Peter Ujfalusi
2015-12-04 13:53 ` Peter Ujfalusi
2015-12-04 13:53 ` Peter Ujfalusi
2015-12-04 13:53 ` [PATCH 1/6] ARM: DTS: da850: fix edma0 reg space Peter Ujfalusi
2015-12-04 13:53   ` Peter Ujfalusi
2015-12-04 13:53   ` Peter Ujfalusi
2015-12-04 13:53 ` [PATCH 2/6] ARM: DTS: da850: Use the new DT bindings for the eDMA3 Peter Ujfalusi
2015-12-04 13:53   ` Peter Ujfalusi
2015-12-04 13:53   ` Peter Ujfalusi
2015-12-15  9:38   ` Sekhar Nori
2015-12-15  9:38     ` Sekhar Nori
2015-12-15  9:38     ` Sekhar Nori
2015-12-15 11:44     ` Peter Ujfalusi
2015-12-15 11:44       ` Peter Ujfalusi
2015-12-15 11:44       ` Peter Ujfalusi
2015-12-15 13:48       ` Sekhar Nori [this message]
2015-12-15 13:48         ` Sekhar Nori
2015-12-15 13:48         ` Sekhar Nori
2015-12-15 14:05         ` Peter Ujfalusi
2015-12-15 14:05           ` Peter Ujfalusi
2015-12-15 14:05           ` Peter Ujfalusi
2015-12-15 15:20           ` Sekhar Nori
2015-12-15 15:20             ` Sekhar Nori
2015-12-15 15:20             ` Sekhar Nori
2015-12-04 13:53 ` [PATCH 3/6] ARM: DTS: da850: Enable eDMA1 Peter Ujfalusi
2015-12-04 13:53   ` Peter Ujfalusi
2015-12-04 13:53   ` Peter Ujfalusi
2015-12-04 13:53 ` [PATCH 4/6] ARM: DTS: da850: Enable DMA use for MMC0 Peter Ujfalusi
2015-12-04 13:53   ` Peter Ujfalusi
2015-12-04 13:53   ` Peter Ujfalusi
2015-12-04 13:53 ` [PATCH 5/6] ARM: DTS: da850: Add node for mmc1 Peter Ujfalusi
2015-12-04 13:53   ` Peter Ujfalusi
2015-12-04 13:53   ` Peter Ujfalusi
2015-12-04 13:53 ` [PATCH 6/6] ARM: DTS: da850: Enable DMA for SPI1 Peter Ujfalusi
2015-12-04 13:53   ` Peter Ujfalusi
2015-12-04 13:53   ` Peter Ujfalusi
2015-12-09  7:19 ` [PATCH 0/6] ARM: DTS: da850: eDMA new bindings and MMC/SPI DMA support Peter Ujfalusi
2015-12-09  7:19   ` Peter Ujfalusi
2015-12-09  7:19   ` Peter Ujfalusi
2015-12-09  7:52   ` Sekhar Nori
2015-12-09  7:52     ` Sekhar Nori
2015-12-09  7:52     ` Sekhar Nori
2015-12-10 12:20 ` Sushaanth Srirangapathi
2015-12-10 12:20   ` Sushaanth Srirangapathi
2015-12-10 12:20   ` Sushaanth Srirangapathi

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=56701A47.9090105@ti.com \
    --to=nsekhar@ti.com \
    --cc=linux-arm-kernel@lists.infradead.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: link
Be 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.