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-next>] [day] [month] [year] [list]
Message-Id: <201308280012.41638.heiko@sntech.de>
Date:	Wed, 28 Aug 2013 00:12:41 +0200
From:	Heiko Stübner <heiko@...ech.de>
To:	kgene.kim@...sung.com
Cc:	Dan Williams <djbw@...com>, Vinod Koul <vinod.koul@...el.com>,
	linus.walleij@...aro.org, Tomasz Figa <tomasz.figa@...il.com>,
	Sylwester Nawrocki <sylvester.nawrocki@...il.com>,
	linux-kernel@...r.kernel.org, linux-samsung-soc@...r.kernel.org
Subject: [PATCH v3 0/4] ARM: S3C24XX: add dmaengine based dma-driver

This series tries to provide a basic dmaengine driver for the s3c24xx
SoCs to subsequently retire the old one with custom API.

Since v2 only some small fixes to the dma driver itself were added.

Since v1 three big changes happened (appart from fixing received comments):

For one the limitation of sg-lists to 1 element is gone.Secondly the
specifics of the virtual channels (target bus, handshake, etc) are not
encoded with channel ids but in the platformdata - making a later dt
binding easier, as these informations can there be gathered by the xlate
function. And lastly I also added a preliminary mechanism to handle the
specific needs for the earlier variants of the driver.

While s3c2443 and later can use any channel for any peripheral with just
marking the target-peripheral-id in a register, earlier SoCs can only use
specific channels and the target-ids also vary depending on the channel.

Therefore on newer SoCs the chansel element only needs to contain the
requested target-id, while on the older variants use it to encode both
the valid channels and the channel-specific peripheral-id.

On affected SoCs the target-id is always 3 bit wide, so we use these and
an additional 4th bit to hold the valid state. As the older SoCs all have
4 dma channels this can live happily in an u16 element.

The s3c24xx series will most likely not see any new offspring, but even
if it happens any new model will probably use the newer more flexible
variant of the dma controller, so this should not restrict anything
in the future.

Example:
SDI is valid on channels 0, 2 and 3 - with varying hw request sources.
For it the chansel field would look like

 ((BIT(3) | 1) << 3 * 4) | // channel 3, with request source 1
 ((BIT(3) | 2) << 2 * 4) | // channel 2, with request source 2
 ((BIT(3) | 2) << 0 * 4)   // channel 0, with request source 2


Heiko Stuebner (4):
  ARM: S3C24XX: number the dma clocks
  dmaengine: add driver for Samsung s3c24xx SoCs
  ARM: S3C24XX: add platform-devices for new dma driver for s3c2412 and
    s3c2443
  ARM: SAMSUNG: set s3c24xx_dma_filter for s3c64xx-spi0 device

 arch/arm/mach-s3c24xx/clock-s3c2412.c     |    8 +-
 arch/arm/mach-s3c24xx/common-s3c2443.c    |   12 +-
 arch/arm/mach-s3c24xx/common.c            |  106 +++
 arch/arm/mach-s3c24xx/common.h            |    3 +
 arch/arm/mach-s3c24xx/mach-jive.c         |    1 +
 arch/arm/mach-s3c24xx/mach-smdk2413.c     |    1 +
 arch/arm/mach-s3c24xx/mach-smdk2416.c     |    1 +
 arch/arm/mach-s3c24xx/mach-smdk2443.c     |    1 +
 arch/arm/mach-s3c24xx/mach-vstms.c        |    1 +
 arch/arm/plat-samsung/devs.c              |    5 +-
 drivers/dma/Kconfig                       |   12 +
 drivers/dma/Makefile                      |    1 +
 drivers/dma/s3c24xx-dma.c                 | 1285 +++++++++++++++++++++++++++++
 include/linux/platform_data/dma-s3c24xx.h |   43 +
 14 files changed, 1469 insertions(+), 11 deletions(-)
 create mode 100644 drivers/dma/s3c24xx-dma.c
 create mode 100644 include/linux/platform_data/dma-s3c24xx.h

-- 
1.7.10.4

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