From: Vinod Koul <vkoul@kernel.org>
To: "Martin Povišer" <povik@cutebit.org>
Cc: "Martin Povišer" <povik+lin@cutebit.org>,
"Hector Martin" <marcan@marcan.st>,
"Sven Peter" <sven@svenpeter.dev>,
"Rob Herring" <robh+dt@kernel.org>,
"Krzysztof Kozlowski" <krzk+dt@kernel.org>,
"Alyssa Rosenzweig" <alyssa@rosenzweig.io>,
linux-arm-kernel@lists.infradead.org, dmaengine@vger.kernel.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
"Mark Kettenis" <kettenis@openbsd.org>
Subject: Re: [PATCH 1/2] dt-bindings: dma: Add Apple ADMAC
Date: Thu, 31 Mar 2022 19:40:00 +0530 [thread overview]
Message-ID: <YkW2OG3dU4YFYJEZ@matsya> (raw)
In-Reply-To: <265B2992-06E5-4E45-A971-B170A385EFD4@cutebit.org>
On 31-03-22, 09:06, Martin Povišer wrote:
>
> > On 31. 3. 2022, at 8:50, Martin Povišer <povik@cutebit.org> wrote:
> >
> >>
> >> On 31. 3. 2022, at 7:23, Vinod Koul <vkoul@kernel.org> wrote:
> >>
> >> On 30-03-22, 18:44, Martin Povišer wrote:
> >>> Apple's Audio DMA Controller (ADMAC) is used to fetch and store audio
> >>> samples on Apple SoCs from the "Apple Silicon" family.
> >>>
> >>> Signed-off-by: Martin Povišer <povik+lin@cutebit.org>
> >>> ---
> >>> .../devicetree/bindings/dma/apple,admac.yaml | 73 +++++++++++++++++++
> >>> 1 file changed, 73 insertions(+)
> >>> create mode 100644 Documentation/devicetree/bindings/dma/apple,admac.yaml
> >>>
> >>> diff --git a/Documentation/devicetree/bindings/dma/apple,admac.yaml b/Documentation/devicetree/bindings/dma/apple,admac.yaml
> >>> new file mode 100644
> >>> index 000000000000..34f76a9a2983
> >>> --- /dev/null
> >>> +++ b/Documentation/devicetree/bindings/dma/apple,admac.yaml
> >
> >>> + apple,internal-irq-destination:
> >>> + $ref: /schemas/types.yaml#/definitions/uint32
> >>> + description: Index influencing internal routing of the IRQs
> >>> + within the peripheral.
> >>
> >> do you have more details for this, is this for peripheral and if so
> >> suited to be in dam-cells?
> >
> > By peripheral I meant the DMA controller itself here.
Dmaengine convention is that peripheral is device which we are doing dma
to/from, like audio controller/fifo here
> > Effectively the controller has four independent IRQ outputs and the driver
> > needs to know which one we are using. (It need to be the same output even
> > for different ADMAC instances on one die.)
That smells like a mux to me.. why not use dma-requests for this?
--
~Vinod
next prev parent reply other threads:[~2022-03-31 14:10 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-03-30 16:44 [PATCH 0/2] Apple ADMAC driver Martin Povišer
2022-03-30 16:44 ` [PATCH 1/2] dt-bindings: dma: Add Apple ADMAC Martin Povišer
2022-03-30 18:32 ` Rob Herring
2022-03-31 5:23 ` Vinod Koul
2022-03-31 6:50 ` Martin Povišer
2022-03-31 7:06 ` Martin Povišer
2022-03-31 14:10 ` Vinod Koul [this message]
2022-03-31 16:13 ` Martin Povišer
2022-03-31 17:21 ` Rob Herring
2022-03-31 19:09 ` Martin Povišer
2022-03-30 16:44 ` [PATCH 2/2] dmaengine: apple-admac: Add Apple ADMAC driver Martin Povišer
2022-03-31 6:25 ` Krzysztof Kozlowski
2022-03-31 9:42 ` Martin Povišer
2022-03-31 9:49 ` Krzysztof Kozlowski
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=YkW2OG3dU4YFYJEZ@matsya \
--to=vkoul@kernel.org \
--cc=alyssa@rosenzweig.io \
--cc=devicetree@vger.kernel.org \
--cc=dmaengine@vger.kernel.org \
--cc=kettenis@openbsd.org \
--cc=krzk+dt@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=marcan@marcan.st \
--cc=povik+lin@cutebit.org \
--cc=povik@cutebit.org \
--cc=robh+dt@kernel.org \
--cc=sven@svenpeter.dev \
/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