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-next>] [day] [month] [year] [list]
Message-ID: <20100812150030.GB27749@pengutronix.de>
Date:	Thu, 12 Aug 2010 17:00:30 +0200
From:	Sascha Hauer <s.hauer@...gutronix.de>
To:	linux-kernel@...r.kernel.org
Cc:	Linus Walleij <linus.ml.walleij@...il.com>,
	Dan Williams <dan.j.williams@...el.com>
Subject: dmaengine questions

Hi,

I am currently looking into implementing the Freescale i.MX SDMA engine
into the dmaengine API. The SDMA engine can handle sg transfers from/to
devices. During implementation some questions came up.

On the i.MX we already have a DMA engine which can do slave dma
transfers, the IPU (drivers/dma/ipu/), which is exclusively used for
image operations. My problem is that I found no way for the clients
to select which DMA engine to use as both have the same capabilities
(DMA_SLAVE).

For the SDMA engine the clients have to pass some platform specific data
to the SDMA engine (dma request line, word width and the like). The
current mechanism is to pass this data through the dma_chan->private
field, which seems more like tunneling instead of passing the data as we
lose type safety. Are there any ideas to improve this?

Sascha



-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ