linux-kernel - [PATCH RFC 0/2] dmaengine: Introduce Scheduled DMA sub-framework

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]

Date:	Sat, 21 Mar 2015 12:42:05 -0700
From:	Maxime Ripard <maxime.ripard@...e-electrons.com>
To:	Vinod Koul <vinod.koul@...el.com>
Cc:	dmaengine@...r.kernel.org, linux-kernel@...r.kernel.org,
	Laurent Pinchart <laurent.pinchart@...asonboard.com>,
	Ludovic Desroches <ludovic.desroches@...el.com>,
	Maxime Ripard <maxime.ripard@...e-electrons.com>
Subject: [PATCH RFC 0/2] dmaengine: Introduce Scheduled DMA sub-framework

Hi everyone,

This patch set aims at introducing a new sub-framework to DMAengine to
ease the dmaengine development, while factorising most of the
"administrative" code each drivers have to duplicate.

Most of the same issues are always seen for new drivers, and are
pointed out at each review. Among the major point of errors, we can
find how to dispatch new descriptors to a new idle channel
efficiently, how to schedule requests when you have more requests than
channels, how to allocate new descriptors, etc.

All of this code is currently duplicated by each and every drivers,
with some variations. Of course, this code is rather error prone, and
most of the drivers will face the same issues.

It's exactly the point of the Scheduled DMA framework to abstract this
away from the drivers, only requiring from the drivers the
hardware-specific behaviour (how to start, stop, pause a channel, how
to start the transfer of a descriptor on a given channel, etc.), LLI
operations (iterators, queuing, accessors, etc.) and an optionnal
scheduling hints function to prevent the core to schedule the transfer
of a descriptor on a channel that wouldn't be able to transfer it.

Please not that this is still at an RFC stage, and that there's still
a few bugs hanging around (resources leaked, the memcpy of the A31 can
only work once, etc.) but this RFC is more headed toward wether we are
on the right path or not, and reviews of the general approach.

Thanks!
Maxime

Maxime Ripard (2):
  dmaengine: Introduce scheduled DMA framework
  dmaengine: sun6i: Convert to scheduled DMA

 drivers/dma/Kconfig         |   4 +
 drivers/dma/Makefile        |   1 +
 drivers/dma/scheduled-dma.c | 571 +++++++++++++++++++++++++++++
 drivers/dma/scheduled-dma.h | 140 ++++++++
 drivers/dma/sun6i-dma.c     | 853 ++++++++++----------------------------------
 5 files changed, 897 insertions(+), 672 deletions(-)
 create mode 100644 drivers/dma/scheduled-dma.c
 create mode 100644 drivers/dma/scheduled-dma.h

-- 
2.3.3

--
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/