linux-kernel - Re: [PATCH] dmaengine: axi-dmac: simple device

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 for Android: free password hash cracker in your pocket

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

Date:   Wed, 16 Oct 2019 10:38:41 +0530
From:   Vinod Koul <vkoul@...nel.org>
To:     Lars-Peter Clausen <lars@...afoo.de>
Cc:     "Ardelean, Alexandru" <alexandru.Ardelean@...log.com>,
        "dmaengine@...r.kernel.org" <dmaengine@...r.kernel.org>,
        "alencar.fmce@...el.gov.br" <alencar.fmce@...el.gov.br>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] dmaengine: axi-dmac: simple device_config operation
 implemented

On 15-10-19, 23:06, Lars-Peter Clausen wrote:

> >> This DMA controller is a bit special.
> >> It gets synthesized in FPGA, so the configuration is fixed and cannot be
> >> changed at runtime. Maybe later we would allow/implement this
> >> functionality, but this is a question for my HDL colleagues.
> >>
> >> Two things are done (in this order):
> >> 1. For some paramters, axi_dmac_parse_chan_dt() is used to determine things
> >> from device-tree; as it's an FPGA core, things are synthesized once and
> >> cannot change (yet)
> >> 2. For other parameters, the axi_dmac_detect_caps() is used to guess some
> >> of them at probe time, by doing some reg reads/writes
> > 
> > So the question for you hw folks is how would a controller work with
> > multiple slave devices, do they need to synthesize it everytime?
> > 
> > Rather than that why cant they make the peripheral addresses
> > programmable so that you dont need updating fpga everytime!
> 
> The DMA has a direct connection to the peripheral and the peripheral
> data port is not connected to the general purpose memory interconnect.
> So you can't write to it by an MMIO address and	 there is no address
> that needs to be configured. For an FPGA based design this is quite a
> good solution in terms of resource usage, performance and simplicity. A
> direct connection requires less resources than connection it to the
> central memory interconnect, while at the same time having lower latency
> and not eating up any additional bandwidth on the central memory connect.

thanks for explanation!

> So slave config in this case is a noop and all it can do is verify that
> the requested configuration matches the available configuration.

okay so noop it is!

-- 
~Vinod