Similarly to paRAM slots, channels can be used by other cores.
Add optional property to configure the reserved channel ranges.
Signed-off-by: Peter Ujfalusi <[email protected]>
---
Documentation/devicetree/bindings/dma/ti-edma.txt | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/Documentation/devicetree/bindings/dma/ti-edma.txt b/Documentation/devicetree/bindings/dma/ti-edma.txt
index 4bbc94d829c8..1198682ada99 100644
--- a/Documentation/devicetree/bindings/dma/ti-edma.txt
+++ b/Documentation/devicetree/bindings/dma/ti-edma.txt
@@ -42,6 +42,9 @@ Optional properties:
- ti,edma-reserved-slot-ranges: PaRAM slot ranges which should not be used by
the driver, they are allocated to be used by for example the
DSP. See example.
+- ti,edma-reserved-chan-ranges: channel ranges which should not be used by
+ the driver, they are allocated to be used by for example the
+ DSP. See example.
------------------------------------------------------------------------------
eDMA3 Transfer Controller
@@ -91,6 +94,8 @@ edma: edma@49000000 {
ti,edma-memcpy-channels = <20 21>;
/* The following PaRAM slots are reserved: 35-44 and 100-109 */
ti,edma-reserved-slot-ranges = <35 10>, <100 10>;
+ /* The following channels are reserved: 35-44 */
+ ti,edma-reserved-chan-ranges = <35 10>;
};
edma_tptc0: tptc@49800000 {
--
Peter
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
On Fri, Aug 23, 2019 at 03:56:17PM +0300, Peter Ujfalusi wrote:
> Similarly to paRAM slots, channels can be used by other cores.
>
> Add optional property to configure the reserved channel ranges.
>
> Signed-off-by: Peter Ujfalusi <[email protected]>
> ---
> Documentation/devicetree/bindings/dma/ti-edma.txt | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/dma/ti-edma.txt b/Documentation/devicetree/bindings/dma/ti-edma.txt
> index 4bbc94d829c8..1198682ada99 100644
> --- a/Documentation/devicetree/bindings/dma/ti-edma.txt
> +++ b/Documentation/devicetree/bindings/dma/ti-edma.txt
> @@ -42,6 +42,9 @@ Optional properties:
> - ti,edma-reserved-slot-ranges: PaRAM slot ranges which should not be used by
> the driver, they are allocated to be used by for example the
> DSP. See example.
> +- ti,edma-reserved-chan-ranges: channel ranges which should not be used by
> + the driver, they are allocated to be used by for example the
> + DSP. See example.
Based on the other thread, I think extending dma-channel-mask to a
uint32-array makes sense here.
Rob
Rob,
On 30/08/2019 1.47, Rob Herring wrote:
> On Fri, Aug 23, 2019 at 03:56:17PM +0300, Peter Ujfalusi wrote:
>> Similarly to paRAM slots, channels can be used by other cores.
>>
>> Add optional property to configure the reserved channel ranges.
>>
>> Signed-off-by: Peter Ujfalusi <[email protected]>
>> ---
>> Documentation/devicetree/bindings/dma/ti-edma.txt | 5 +++++
>> 1 file changed, 5 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/dma/ti-edma.txt b/Documentation/devicetree/bindings/dma/ti-edma.txt
>> index 4bbc94d829c8..1198682ada99 100644
>> --- a/Documentation/devicetree/bindings/dma/ti-edma.txt
>> +++ b/Documentation/devicetree/bindings/dma/ti-edma.txt
>> @@ -42,6 +42,9 @@ Optional properties:
>> - ti,edma-reserved-slot-ranges: PaRAM slot ranges which should not be used by
>> the driver, they are allocated to be used by for example the
>> DSP. See example.
>> +- ti,edma-reserved-chan-ranges: channel ranges which should not be used by
>> + the driver, they are allocated to be used by for example the
>> + DSP. See example.
>
> Based on the other thread, I think extending dma-channel-mask to a
> uint32-array makes sense here.
Yes, that is the reason I have asked on that and I'm in progress of
converting the edma driver to use the dma-channel-mask.
Just need to do some shuffling in the driver to get the mask in a form
usable by the driver.
I'll send an updated series early next week.
- Péter
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
Hi Rob,
On 30/08/2019 8.37, Peter Ujfalusi wrote:
> Rob,
>
> On 30/08/2019 1.47, Rob Herring wrote:
>> On Fri, Aug 23, 2019 at 03:56:17PM +0300, Peter Ujfalusi wrote:
>>> Similarly to paRAM slots, channels can be used by other cores.
>>>
>>> Add optional property to configure the reserved channel ranges.
>>>
>>> Signed-off-by: Peter Ujfalusi <[email protected]>
>>> ---
>>> Documentation/devicetree/bindings/dma/ti-edma.txt | 5 +++++
>>> 1 file changed, 5 insertions(+)
>>>
>>> diff --git a/Documentation/devicetree/bindings/dma/ti-edma.txt b/Documentation/devicetree/bindings/dma/ti-edma.txt
>>> index 4bbc94d829c8..1198682ada99 100644
>>> --- a/Documentation/devicetree/bindings/dma/ti-edma.txt
>>> +++ b/Documentation/devicetree/bindings/dma/ti-edma.txt
>>> @@ -42,6 +42,9 @@ Optional properties:
>>> - ti,edma-reserved-slot-ranges: PaRAM slot ranges which should not be used by
>>> the driver, they are allocated to be used by for example the
>>> DSP. See example.
>>> +- ti,edma-reserved-chan-ranges: channel ranges which should not be used by
>>> + the driver, they are allocated to be used by for example the
>>> + DSP. See example.
>>
>> Based on the other thread, I think extending dma-channel-mask to a
>> uint32-array makes sense here.
>
> Yes, that is the reason I have asked on that and I'm in progress of
> converting the edma driver to use the dma-channel-mask.
> Just need to do some shuffling in the driver to get the mask in a form
> usable by the driver.
>
> I'll send an updated series early next week.
How should the dma-channel-mask uint31-array should be documented and used?
Basically some EDMA have 32, some 64 channels. This is fine.
Let's say I want to mask out channel 0-4 and 24-27
This would look like in case of EDMA with 32 channels:
&edma {
/* channel 0-4 and 24-27 is not to be used */
dma-channel-mask = <0xf0fffff0>;
};
How this should look like in case when I have 64 channels?
&edma {
/* channel 0-4 and 24-27 is not to be used */
dma-channel-mask = <0xf0fffff0>, <0xffffffff>;
};
When I read the u32s then
chan_mask[0] is for channel 0-31 (LSB is channel 0)
chan_maks[1] is for channel 32-63 (LSB is channel 32)
Or:
&edma {
/* channel 0-4 and 24-27 is not to be used */
dma-channel-mask = <0xffffffff>, <0xf0fffff0>;
};
chan_maks[0] is for channel 32-63 (LSB is channel 32)
chan_mask[1] is for channel 0-31 (LSB is channel 0)
Do you have pointer on already established notion on how to document and
handle this?
- Péter
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
On Tue, Sep 3, 2019 at 11:19 AM Peter Ujfalusi <[email protected]> wrote:
>
> Hi Rob,
>
> On 30/08/2019 8.37, Peter Ujfalusi wrote:
> > Rob,
> >
> > On 30/08/2019 1.47, Rob Herring wrote:
> >> On Fri, Aug 23, 2019 at 03:56:17PM +0300, Peter Ujfalusi wrote:
> >>> Similarly to paRAM slots, channels can be used by other cores.
> >>>
> >>> Add optional property to configure the reserved channel ranges.
> >>>
> >>> Signed-off-by: Peter Ujfalusi <[email protected]>
> >>> ---
> >>> Documentation/devicetree/bindings/dma/ti-edma.txt | 5 +++++
> >>> 1 file changed, 5 insertions(+)
> >>>
> >>> diff --git a/Documentation/devicetree/bindings/dma/ti-edma.txt b/Documentation/devicetree/bindings/dma/ti-edma.txt
> >>> index 4bbc94d829c8..1198682ada99 100644
> >>> --- a/Documentation/devicetree/bindings/dma/ti-edma.txt
> >>> +++ b/Documentation/devicetree/bindings/dma/ti-edma.txt
> >>> @@ -42,6 +42,9 @@ Optional properties:
> >>> - ti,edma-reserved-slot-ranges: PaRAM slot ranges which should not be used by
> >>> the driver, they are allocated to be used by for example the
> >>> DSP. See example.
> >>> +- ti,edma-reserved-chan-ranges: channel ranges which should not be used by
> >>> + the driver, they are allocated to be used by for example the
> >>> + DSP. See example.
> >>
> >> Based on the other thread, I think extending dma-channel-mask to a
> >> uint32-array makes sense here.
> >
> > Yes, that is the reason I have asked on that and I'm in progress of
> > converting the edma driver to use the dma-channel-mask.
> > Just need to do some shuffling in the driver to get the mask in a form
> > usable by the driver.
> >
> > I'll send an updated series early next week.
>
> How should the dma-channel-mask uint31-array should be documented and used?
>
> Basically some EDMA have 32, some 64 channels. This is fine.
> Let's say I want to mask out channel 0-4 and 24-27
>
> This would look like in case of EDMA with 32 channels:
> &edma {
> /* channel 0-4 and 24-27 is not to be used */
> dma-channel-mask = <0xf0fffff0>;
> };
>
> How this should look like in case when I have 64 channels?
> &edma {
> /* channel 0-4 and 24-27 is not to be used */
> dma-channel-mask = <0xf0fffff0>, <0xffffffff>;
> };
>
> When I read the u32s then
> chan_mask[0] is for channel 0-31 (LSB is channel 0)
> chan_maks[1] is for channel 32-63 (LSB is channel 32)
>
> Or:
> &edma {
> /* channel 0-4 and 24-27 is not to be used */
> dma-channel-mask = <0xffffffff>, <0xf0fffff0>;
> };
>
> chan_maks[0] is for channel 32-63 (LSB is channel 32)
> chan_mask[1] is for channel 0-31 (LSB is channel 0)
>
> Do you have pointer on already established notion on how to document and
> handle this?
As far as word ordering, I guess you can do whatever order you want.
MSB first would make the most sense if this was only going to be up to
64-bit. But given it could be 96, 128, ... bits, probably the least
significant word first makes sense and is easier to parse for a
variable length.
The binding schema can be something like this:
items:
- description: Mask of channels 0-31
- description: Mask of channels 32-63
The length is implied by the number of list items.
Rob