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] [thread-next>] [day] [month] [year] [list]
Date:   Wed, 4 Oct 2023 15:41:35 +0200
From:   Martin Povišer <povik+lin@...ebit.org>
To:     Vinod Koul <vkoul@...nel.org>
Cc:     Rob Herring <robh+dt@...nel.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
        Conor Dooley <conor+dt@...nel.org>, asahi@...ts.linux.dev,
        dmaengine@...r.kernel.org, devicetree@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 2/2] dmaengine: apple-sio: Add Apple SIO driver



> On 4. 10. 2023, at 15:32, Martin Povišer <povik+lin@...ebit.org> wrote:
> 
> 
> Hello Vinod,
> 
> some of those things we have discussed on v1 already, let me link
> that here:
> https://lore.kernel.org/asahi/20230712133806.4450-1-povik+lin@cutebit.org/T/#t
> 
> Anyway find my replies below.
> 
> Best regards, Martin
> 
>> On 4. 10. 2023, at 15:12, Vinod Koul <vkoul@...nel.org> wrote:
>> 
>> On 28-08-23, 19:00, Martin Povišer wrote:
>>> Add a dmaengine driver for the Apple SIO coprocessor found on Apple
>>> SoCs where it provides DMA services. Have the driver support cyclic
>>> transactions so that ALSA drivers can rely on it in audio output to
>>> HDMI and DisplayPort.
>>> 
>>> Signed-off-by: Martin Povišer <povik+lin@...ebit.org>
>>> ---
>>> MAINTAINERS             |   2 +
>>> drivers/dma/Kconfig     |  11 +
>>> drivers/dma/Makefile    |   1 +
>>> drivers/dma/apple-sio.c | 868 ++++++++++++++++++++++++++++++++++++++++
>>> 4 files changed, 882 insertions(+)
>>> create mode 100644 drivers/dma/apple-sio.c

...

>>> +/*
>>> + * There are two kinds of 'transaction descriptors' in play here.
>>> + *
>>> + * There's the struct sio_tx, and the struct dma_async_tx_descriptor embedded
>>> + * inside, which jointly represent a transaction to the dmaengine subsystem.
>>> + * At this time we only support those transactions to be cyclic.
>>> + *
>>> + * Then there are the coprocessor descriptors, which is what the coprocessor
>>> + * knows and understands. These don't seem to have a cyclic regime, so we can't
>>> + * map the dmaengine transaction on an exact coprocessor counterpart. Instead
>>> + * we continually queue up many coprocessor descriptors to implement a cyclic
>>> + * transaction.
>>> + *
>>> + * The number below is the maximum of how far ahead (how many) coprocessor
>>> + * descriptors we should be queuing up, per channel, for a cyclic transaction.
>>> + * Basically it's a made-up number.
>>> + */
>>> +#define SIO_MAX_NINFLIGHT 4
>> 
>> you meant SIO_MAX_INFLIGHT if not what is NINFLIGHT?
> 
> I mean the number is arbitrary, it doesn’t reflect any coprocessor limit since
> I haven’t run the tests to figure one out. It's supposed to be a small reasonable
> number.

Ah I didn’t get what you were commenting on at first. Sure, INFLIGHT, NINFLIGHT,
it’s the same thing to me. I have a tendency to put in the N to signify it’s
the “number of”.

Best,
Martin

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ