dmaengine.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: <Eugen.Hristev@microchip.com>
To: <vkoul@kernel.org>
Cc: <robh@kernel.org>, <Tudor.Ambarus@microchip.com>,
	<Ludovic.Desroches@microchip.com>, <dmaengine@vger.kernel.org>,
	<devicetree@vger.kernel.org>,
	<linux-arm-kernel@lists.infradead.org>,
	<linux-kernel@vger.kernel.org>, <Nicolas.Ferre@microchip.com>
Subject: Re: [PATCH 6/7] dt-bindings: dmaengine: at_xdmac: add optional microchip,m2m property
Date: Fri, 16 Oct 2020 07:09:12 +0000	[thread overview]
Message-ID: <d8a016cb-7f80-c8d2-9711-12377452d420@microchip.com> (raw)
In-Reply-To: <20201016070618.GW2968@vkoul-mobl>

On 16.10.2020 10:06, Vinod Koul wrote:
> Hi Eugen,
> 
> On 16-10-20, 06:45, Eugen.Hristev@microchip.com wrote:
>> On 23.09.2020 02:33, Rob Herring wrote:
>>
>>> On Mon, Sep 14, 2020 at 05:09:55PM +0300, Eugen Hristev wrote:
>>>> Add optional microchip,m2m property that specifies if a controller is
>>>> dedicated to memory to memory operations only.
>>>>
>>>> Signed-off-by: Eugen Hristev <eugen.hristev@microchip.com>
>>>> ---
>>>>    Documentation/devicetree/bindings/dma/atmel-xdma.txt | 6 ++++++
>>>>    1 file changed, 6 insertions(+)
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/dma/atmel-xdma.txt b/Documentation/devicetree/bindings/dma/atmel-xdma.txt
>>>> index 510b7f25ba24..642da6b95a29 100644
>>>> --- a/Documentation/devicetree/bindings/dma/atmel-xdma.txt
>>>> +++ b/Documentation/devicetree/bindings/dma/atmel-xdma.txt
>>>> @@ -15,6 +15,12 @@ the dmas property of client devices.
>>>>        interface identifier,
>>>>        - bit 30-24: PERID, peripheral identifier.
>>>>
>>>> +Optional properties:
>>>> +- microchip,m2m: this controller is connected on AXI only to memory and it's
>>>> +     dedicated to memory to memory DMA operations. If this option is
>>>> +     missing, it's assumed that the DMA controller is connected to
>>>> +     peripherals, thus it's a per2mem and mem2per.
>>>
>>> Wouldn't 'dma-requests = <0>' cover this case?
>>>
>>> Rob
>>>
>>
>> Hi Rob,
>>
>> I do not think so. With requests = 0, it means that actually the DMA
>> controller is unusable ?
>> Since you suggest requests = 0, it means that it cannot take requests at
>> all ?
>> I do not find another example in current DT with this property set to zero.
> 
> Not really, dma-requests implies "request signals supported" which are
> used for peripheral cases. m2m does not need request signals, so it is
> very reasonable to conclude that dma-requests = <0> would imply no
> peripheral support and only m2m support.

Thanks for explaining, I will change accordingly then.

Eugen

> 
> Thanks
> --
> ~Vinod
> 


  reply	other threads:[~2020-10-16  7:09 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-14 14:09 [PATCH 0/7] dmaengine: add support for sama7g5 based at_xdmac Eugen Hristev
2020-09-14 14:09 ` [PATCH 1/7] dmaengine: at_xdmac: separate register defines into header file Eugen Hristev
2020-09-23  5:07   ` Tudor.Ambarus
2020-09-14 14:09 ` [PATCH 2/7] MAINTAINERS: add dma/at_xdmac_regs.h to XDMAC driver entry Eugen Hristev
2020-09-23  5:12   ` Tudor.Ambarus
2020-09-14 14:09 ` [PATCH 3/7] dt-bindings: dmaengine: at_xdmac: add compatible with microchip,sama7g5 Eugen Hristev
2020-09-22 23:32   ` Rob Herring
2020-09-14 14:09 ` [PATCH 4/7] dmaengine: at_xdmac: adapt perid for mem2mem operations Eugen Hristev
2020-09-23  5:30   ` Tudor.Ambarus
2020-09-23  5:35     ` Tudor.Ambarus
2020-09-14 14:09 ` [PATCH 5/7] dmaengine: at_xdmac: add support for sama7g5 based at_xdmac Eugen Hristev
2020-09-23  7:08   ` Tudor.Ambarus
2020-10-16  6:52     ` Eugen.Hristev
2020-09-14 14:09 ` [PATCH 6/7] dt-bindings: dmaengine: at_xdmac: add optional microchip,m2m property Eugen Hristev
2020-09-22 23:33   ` Rob Herring
2020-10-16  6:45     ` Eugen.Hristev
2020-10-16  7:06       ` Vinod Koul
2020-10-16  7:09         ` Eugen.Hristev [this message]
2020-09-14 14:09 ` [PATCH 7/7] dmaengine: at_xdmac: add AXI priority support and recommended settings Eugen Hristev

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=d8a016cb-7f80-c8d2-9711-12377452d420@microchip.com \
    --to=eugen.hristev@microchip.com \
    --cc=Ludovic.Desroches@microchip.com \
    --cc=Nicolas.Ferre@microchip.com \
    --cc=Tudor.Ambarus@microchip.com \
    --cc=devicetree@vger.kernel.org \
    --cc=dmaengine@vger.kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=robh@kernel.org \
    --cc=vkoul@kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).