Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1264584 > unrolled thread

Re: [PATCH v2 2/3] dmaengine: ti-dma-crossbar: dra7: Support for reserving DMA event ranges

Started byRob Herring <robh@kernel.org>
First post2015-11-06 23:00 +0100
Last post2015-11-09 09:30 +0100
Articles 2 — 2 participants

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.


Contents

  Re: [PATCH v2 2/3] dmaengine: ti-dma-crossbar: dra7: Support for  reserving DMA event ranges Rob Herring <robh@kernel.org> - 2015-11-06 23:00 +0100
    Re: [PATCH v2 2/3] dmaengine: ti-dma-crossbar: dra7: Support for  reserving DMA event ranges Peter Ujfalusi <peter.ujfalusi@ti.com> - 2015-11-09 09:30 +0100

#1264584 — Re: [PATCH v2 2/3] dmaengine: ti-dma-crossbar: dra7: Support for reserving DMA event ranges

FromRob Herring <robh@kernel.org>
Date2015-11-06 23:00 +0100
SubjectRe: [PATCH v2 2/3] dmaengine: ti-dma-crossbar: dra7: Support for reserving DMA event ranges
Message-ID<qrXd8-1Iu-7@gated-at.bofh.it>
On Fri, Oct 30, 2015 at 10:00:37AM +0200, Peter Ujfalusi wrote:
> In eDMA the events are directly mapped to a DMA channel (for example DMA
> event 14 can only be handled by DMA channel 14). If the memcpy is enabled
> on the eDMA, there is a possibility that the crossbar driver would assign
> DMA event number already allocated in eDMA for memcpy. Furthermore the
> eDMA can be shared with DSP in which case the crossbar driver should also
> avoid mapping xbar events to DSP used event numbers (or channels).
> 
> Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
> ---
>  .../devicetree/bindings/dma/ti-dma-crossbar.txt    |  6 +++
>  drivers/dma/ti-dma-crossbar.c                      | 47 ++++++++++++++++++++--
>  2 files changed, 49 insertions(+), 4 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/dma/ti-dma-crossbar.txt b/Documentation/devicetree/bindings/dma/ti-dma-crossbar.txt
> index b152a75dceae..aead5869a28d 100644
> --- a/Documentation/devicetree/bindings/dma/ti-dma-crossbar.txt
> +++ b/Documentation/devicetree/bindings/dma/ti-dma-crossbar.txt
> @@ -14,6 +14,10 @@ The DMA controller node need to have the following poroperties:
>  
>  Optional properties:
>  - ti,dma-safe-map: Safe routing value for unused request lines
> +- ti,reserved-dma-request-ranges: DMA request ranges which should not be used
> +		when mapping xbar input to DMA request, they are either
> +		allocated to be used by for example the DSP or they are used as
> +		memcpy channels in eDMA.

How many requests are there? I think I'd rather see this as a mask 
value.

Rob
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [next] | [standalone]


#1265447

FromPeter Ujfalusi <peter.ujfalusi@ti.com>
Date2015-11-09 09:30 +0100
Message-ID<qsPZU-3W1-1@gated-at.bofh.it>
In reply to#1264584
On 11/06/2015 11:53 PM, Rob Herring wrote:
> On Fri, Oct 30, 2015 at 10:00:37AM +0200, Peter Ujfalusi wrote:
>> In eDMA the events are directly mapped to a DMA channel (for example DMA
>> event 14 can only be handled by DMA channel 14). If the memcpy is enabled
>> on the eDMA, there is a possibility that the crossbar driver would assign
>> DMA event number already allocated in eDMA for memcpy. Furthermore the
>> eDMA can be shared with DSP in which case the crossbar driver should also
>> avoid mapping xbar events to DSP used event numbers (or channels).
>>
>> Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
>> ---
>>  .../devicetree/bindings/dma/ti-dma-crossbar.txt    |  6 +++
>>  drivers/dma/ti-dma-crossbar.c                      | 47 ++++++++++++++++++++--
>>  2 files changed, 49 insertions(+), 4 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/dma/ti-dma-crossbar.txt b/Documentation/devicetree/bindings/dma/ti-dma-crossbar.txt
>> index b152a75dceae..aead5869a28d 100644
>> --- a/Documentation/devicetree/bindings/dma/ti-dma-crossbar.txt
>> +++ b/Documentation/devicetree/bindings/dma/ti-dma-crossbar.txt
>> @@ -14,6 +14,10 @@ The DMA controller node need to have the following poroperties:
>>  
>>  Optional properties:
>>  - ti,dma-safe-map: Safe routing value for unused request lines
>> +- ti,reserved-dma-request-ranges: DMA request ranges which should not be used
>> +		when mapping xbar input to DMA request, they are either
>> +		allocated to be used by for example the DSP or they are used as
>> +		memcpy channels in eDMA.
> 
> How many requests are there? I think I'd rather see this as a mask 
> value.

The eDMA on dra7 family have 64 channels. I don't have visibility to customer
kernels, but at least 32 channels need be allocated to be used by the DSP.
This depends on the system design. It could be that only the memcpy channels
need to be reserved, but in some setups we do need more than a few.

-- 
Péter
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [standalone]


Back to top | Article view | linux.kernel


csiph-web