linux-kernel - Re: dmaengine questions

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:	Fri, 13 Aug 2010 00:32:08 +0200
From:	Linus Walleij <linus.ml.walleij@...il.com>
To:	Sascha Hauer <s.hauer@...gutronix.de>
Cc:	Dan Williams <dan.j.williams@...el.com>,
	linux-kernel@...r.kernel.org
Subject: Re: dmaengine questions

2010/8/12 Sascha Hauer <s.hauer@...gutronix.de>:
> [Dan]
>> Hopefully dma_chan->private can eventually be phased out in favor of
>> Linus' dma_slave_config scheme [1].
>
> This looks promising. Two things are missing here for the SDMA engine.
> First is the DMA request line which is probably needed for other dma
> engines aswell, so this could be added to dma_slave_config.

Do you really need to configure this at runtime?
The idea is to pass in stuff that is changed dynamically wheras
things that are fixed are passed in from platform data.

In the PL180 there was multiplexing functions for the lines even
(so one line was shared between different devices) in that case
I implemented platform-specific callbacks in the platform data
to request the lines.

> The other
> one is really specific to the SDMA engine, it's the following enum. The
> SDMA engine is a programmable controller in the i.MX and each peripheral
> has its own copy function in this controller. This enum is used to
> determine their start addresses.

Can't you pass in the actual address in src_address for RX and
dst_address for TX?

The idea here is that the driver know the physical address where
the bitpipe is supposed to end up, and the DMAengine does not.
If it was always the same address we could pass that also through
platform data but experience shows that some devices use different
addresses for different kinds of configurations, that's why it's there.

Maybe I'm just not getting it...

Yours,
Linus Walleij
--
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/