Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752956AbbGFOtH (ORCPT ); Mon, 6 Jul 2015 10:49:07 -0400 Received: from mx0b-00176a03.pphosted.com ([67.231.157.48]:6258 "EHLO mx0b-00176a03.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751439AbbGFOtD (ORCPT ); Mon, 6 Jul 2015 10:49:03 -0400 Message-ID: <559A9556.4040303@ge.com> Date: Mon, 6 Jul 2015 15:48:54 +0100 From: Martyn Welch User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Dmitry Kalinkin CC: Greg Kroah-Hartman , , , Manohar Vanga , Igor Alekseev Subject: Re: [PATCHv3 08/16] staging: vme_user: provide DMA functionality References: <1432814833-5320-1-git-send-email-dmitry.kalinkin@gmail.com> <1432814833-5320-9-git-send-email-dmitry.kalinkin@gmail.com> <20150613002807.GA17459@kroah.com> <559A8117.4060701@ge.com> In-Reply-To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [3.159.212.193] X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2015-07-06_07:,, signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=2 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1506180000 definitions=main-1507060229 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2427 Lines: 52 On 06/07/15 14:50, Dmitry Kalinkin wrote: > On Mon, Jul 6, 2015 at 4:22 PM, Martyn Welch wrote: >> >> Sorry about the *really* late reply, loads of emails some how missed my >> periodic search of the mailing list. >> >> I'm happy with the addition of DMA, just not sure whether it's worth adding >> an extra device file just to handle DMA. Could the user space application >> not just use the control device? > That would require an additional ioctl field for DMA channel id in case we want > to support both DMA channels on tsi148. > Or just dynamically allocate and free a resource for the DMA operation? > It would make sense to save that device minor if Documentation/devices.txt > was good. > But it has only 4 slave and 4 master windows whereas we would want to > make some parameters for vme_user to configure this allocation numbers up > to 8 slaves and 8 masters. > The vme_user module was originally envisaged as a mechanism to provide support for applications that had been written to use the original driver at vmelinux.org. Some functionality was dropped as it was not good practice (such as receiving VME interrupts in user space, it's not really doable if the slave card is Release On Register Access rather than Release on Acknowledge), so the interface became more of a debug mechanism for me. Others have clearly found it provides enough for them to allow drivers to be written in user space. I was thinking that the opposite might be better, no windows were mapped at module load, windows could be allocated and mapped using the control device. This would ensure that unused resources were still available for kernel based drivers and would mean the driver wouldn't be pre-allocating a bunch of fairly substantially sized slave window buffers (the buffers could also be allocated to match the size of the slave window requested). What do you think? -- Martyn Welch (Lead Software Engineer) | Registered in England and Wales GE Intelligent Platforms | (3828642) at 100 Barbirolli Square T +44(0)1327322748 | Manchester, M2 3AB E martyn.welch@ge.com | VAT:GB 927559189 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/