[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-Id: <1432814833-5320-1-git-send-email-dmitry.kalinkin@gmail.com>
Date: Thu, 28 May 2015 15:06:57 +0300
From: Dmitry Kalinkin <dmitry.kalinkin@...il.com>
To: linux-kernel@...r.kernel.org, devel@...verdev.osuosl.org
Cc: Martyn Welch <martyn.welch@...com>,
Manohar Vanga <manohar.vanga@...il.com>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Igor Alekseev <igor.alekseev@...p.ru>,
Dmitry Kalinkin <dmitry.kalinkin@...il.com>
Subject: [PATCHv3 00/16] vme DMA and user space driver improvements
The first item in this submission documents previously introduced
vme_master_mmap() call. Following, there are three fixes for the tsi148
driver's DMA. There was one bug that rendered it imposible to use DMA
lists with more than one item. The other was related to the place where
dma_map_single was called on the first DMA descriptor in the DMA list. The
last bug was about DMA transfer not stopping at interruption by signal,
which is a possible DoS attack vector. I also made an attempt to fix the
same issue in the ca91cx42 driver. I don't have access to this hardware to
test, so this is based only on my understanding of the datasheet (checked
ca91c042's errata as well).
A new /sys/bus/vme/dma0 device with a new ioctl for making DMA transfers
was introduced in vme_user driver. The logic of the function is similar to
the one found in existing drivers.
One question that I had while implementing this feature was whether we
should keep vme_dma_attr objects until vme_dma_list_exec() call. API
doesn't specify this, the existing vme bridge drivers copy all information
from attributes during vme_dma_list_add(). So for simplicity this
implementation frees vme_dma_attr's before vme_dma_list_exec() is done.
A simple test against AVM16 board displays speeds around 45 MiB/s for
A32/D32 reads for both BLT and MBLT (with MBLT being slightly faster).
Changes in v2 [patches 1-6, now 1-5 and 8]:
* vme_addr check for vme_user DMA
* limit on DMA operation length in vme_user
* reorder dma_op ioctl struct to omit __packed attribute
* change dma_op->write into dma_op->dir
* use vme_check_window assure DMA operation correctness
New changes include vme_user code cleanup, a couple of ca91cx42 fixes
(again, tested for compilation only).
I also propose a change to export some of VME subsytem related constants
to the user space. These can be useful if vme_user is to go into the kernel.
Also, email
http://driverdev.linuxdriverproject.org/pipermail/driverdev-devel/2012-July/029084.html
mentions that we probably can now get rid of this comment:
> /* XXX We do not want to push aspace, cycle and width
> * to userspace as they are
> */
v3 adresses code style problems
Dmitry Kalinkin (16):
Documentation: mention vme_master_mmap() in VME API
vme: tsi148: fix DMA lists longer that one item
vme: tsi148: fix first DMA item mapping
vme: stop DMA transfer on interruption
staging: vme_user: refactor llseek to switch(){}
vme: check for A64 overflow in vme_check_window()
vme: export vme_check_window()
staging: vme_user: provide DMA functionality
vme: ca91cx42: return error code on DMA error
vme: ca91cx42: fix LM_CTL address mask
staging: vme_user: remove unused counters
staging: vme_user: remove forward declarations
staging: vme_user: remove open/release
staging: vme_user: remove buf_unalloc helper
vme: tsi148: depend on HAS_DMA for Kconfig
vme: provide uapi header
Documentation/vme_api.txt | 6 +
drivers/staging/vme/devices/vme_user.c | 454 +++++++++++++++++++--------------
drivers/staging/vme/devices/vme_user.h | 11 +
drivers/vme/bridges/Kconfig | 2 +-
drivers/vme/bridges/vme_ca91cx42.c | 18 +-
drivers/vme/bridges/vme_ca91cx42.h | 2 +-
drivers/vme/bridges/vme_tsi148.c | 42 +--
drivers/vme/vme.c | 11 +-
include/linux/vme.h | 56 +---
include/uapi/linux/Kbuild | 1 +
include/uapi/linux/vme.h | 56 ++++
11 files changed, 394 insertions(+), 265 deletions(-)
create mode 100644 include/uapi/linux/vme.h
--
1.8.3.1
--
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