Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932546AbbGTIJ4 (ORCPT ); Mon, 20 Jul 2015 04:09:56 -0400 Received: from mx0b-00176a03.pphosted.com ([67.231.157.48]:34791 "EHLO mx0b-00176a03.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932301AbbGTIJw (ORCPT ); Mon, 20 Jul 2015 04:09:52 -0400 Message-ID: <55ACACA7.6020006@ge.com> Date: Mon, 20 Jul 2015 09:09:11 +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: Generic VME UIO driver 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> <559A9556.4040303@ge.com> <559D2415.1060502@ge.com> <6296E8BD-06B6-4FC2-859A-98B2E2ED66BF@gmail.com> In-Reply-To: <6296E8BD-06B6-4FC2-859A-98B2E2ED66BF@gmail.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [3.159.212.192] X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2015-07-20_01:,, signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1506180000 definitions=main-1507200131 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2142 Lines: 50 On 08/07/15 16:02, Dmitry Kalinkin wrote: > >> On 08 Jul 2015, at 16:22, Martyn Welch wrote: >> >> On 06/07/15 18:24, Dmitry Kalinkin wrote: >>>> 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), >>> Didn't know about RORA. I wonder how different this is compared to the >>> PCI bus case. >> >> Little I suspect. What it does mean is that there's no generic mechanism for clearing down an interrupt, so a device specific interrupt routine is required, which needs to be in kernel space. > Yet PCI somehow managed to settle with UIO. "If, on the other hand, your hardware needs some action to be performed after each interrupt, then you must do it in your kernel module." https://www.kernel.org/doc/htmldocs/uio-howto/adding_irq_handler.html > Now imagine I am working with a board using vme_user API and I need to > implement interrupts. The PCI case teaches me that I need to write a board specific > UIO driver. My board is ROAK and allows to configure it's interrupt to any level and > any status/id. So I only use a standard vme_irq_request API that generates IACK > cycle for me automatically. I also don’t want to limit my end user with a choice of > interrupt level and status/id and so I make it configurable. In the end I’ve got a very > generic ROAK device driver. What did I do wrong? > Nothing by the sounds of it. If you have ROAK hardware, life is a lot simpler. Martyn > Cheers, > Dmitry > -- 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/