linux-kernel - Re: [PATCH 1/2] dt-bindings: dma: Add Apple ADMAC

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-Id: <13047464-BDFC-455C-AC5E-E7BC249908F3@cutebit.org>
Date:   Thu, 31 Mar 2022 21:09:05 +0200
From:   Martin Povišer <povik@...ebit.org>
To:     Rob Herring <robh@...nel.org>
Cc:     Vinod Koul <vkoul@...nel.org>,
        Martin Povišer <povik+lin@...ebit.org>,
        Hector Martin <marcan@...can.st>,
        Sven Peter <sven@...npeter.dev>,
        Krzysztof Kozlowski <krzk+dt@...nel.org>,
        Alyssa Rosenzweig <alyssa@...enzweig.io>,
        linux-arm-kernel@...ts.infradead.org, dmaengine@...r.kernel.org,
        devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
        Mark Kettenis <kettenis@...nbsd.org>
Subject: Re: [PATCH 1/2] dt-bindings: dma: Add Apple ADMAC



> On 31. 3. 2022, at 19:21, Rob Herring <robh@...nel.org> wrote:
> 
> On Thu, Mar 31, 2022 at 06:13:53PM +0200, Martin Povišer wrote:
>> 
>>> On 31. 3. 2022, at 16:10, Vinod Koul <vkoul@...nel.org> wrote:
>>> 
>>> On 31-03-22, 09:06, Martin Povišer wrote:
>>>> 
>>>>> On 31. 3. 2022, at 8:50, Martin Povišer <povik@...ebit.org> wrote:
>>>>>> 
>>>>>> On 31. 3. 2022, at 7:23, Vinod Koul <vkoul@...nel.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@...ebit.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 not 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?
>> 
>> I am not sure that’s right. Reading the dmaengine docs, DMA requests seem to have
>> to do with the DMA-controller-to-peripheral connection, but the proposed property
>> tells us which of four independent IRQ outputs of the DMA controller we actually
>> have in the interrupts= property. That is, it has to do with the DMA-controller-to-CPU
>> connection.
> 
> Why do they have to be different? IRQF_SHARED doesn't work?

It’s not that the IRQ outputs of different controllers are overlaid. It’s
that e.g. first output of controller A is hooked up to some input of the AP’s
interrupt controller, the third output of controller B is hooked to another
input, but for all we know the other controller outputs lead to nowhere or
to some coprocessor.

> Why can't you request each IRQ until it succeeds?
> 
> What happens when there are 5 DMA controllers?
> 
> If using more than 1 interrupt will never work or be needed, then I'm 
> inclined to say just describe that 1 interrupt. Yes, that goes against 
> 'describe all the h/w', but there's always exceptions. I suppose you 
> need to know which 'interrupts' index (output) you are using. If so, you 
> can do something like this:
> 
> interrupts = <-1>, <-1>, <3 0>, <-1>;

That’s actually exactly what I want! In next iteration of the binding I will
drop the vendor property and do that.

> 
> Rob

Martin