Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757218AbbGGMvW (ORCPT ); Tue, 7 Jul 2015 08:51:22 -0400 Received: from mail-qk0-f169.google.com ([209.85.220.169]:32859 "EHLO mail-qk0-f169.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756987AbbGGMvO convert rfc822-to-8bit (ORCPT ); Tue, 7 Jul 2015 08:51:14 -0400 MIME-Version: 1.0 In-Reply-To: <78FC1849-FFE4-49E5-8421-25D27324F790@gmail.com> 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> <78FC1849-FFE4-49E5-8421-25D27324F790@gmail.com> Date: Tue, 7 Jul 2015 14:51:13 +0200 Message-ID: Subject: Re: [PATCHv3 08/16] staging: vme_user: provide DMA functionality From: Alessio Igor Bogani To: Dmitry Kalinkin Cc: Martyn Welch , devel@driverdev.osuosl.org, Greg Kroah-Hartman , Igor Alekseev , LKML , Manohar Vanga Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2125 Lines: 54 Hi Dmitry, On 7 July 2015 at 12:47, Dmitry Kalinkin wrote: [...] > The API I had in mind would have only vme_master_read and vme_master_write > that would take absolute addresses (not relative to any window). These > variants > of access functions would then try to reuse any window that is already able > to serve > the request or wait for a free window and reconfigure it for the need of the > request. > After usage the window is to be returned back to the window pool. Interesting approach. > Other way to implement these would be to use DMA for everything, since it > doesn’t > have the limitations that the windows have. > On 07 Jul 2015, at 10:08, Alessio Igor Bogani > wrote: [...] >> In fact this is a big obstacle for adoption of this VME stack (at least for >> us). We use VME a lot and we care about latency as well so we use only >> kernel-space drivers for ours VME boards but unfortunately the VME stack let >> us to link a single board with a single window/image (so max 8 boards on >> tsi148) only. That said that stack has proven to be very rock solid. > > Current VME stack links windows not to the boards, but to device drivers. > Driver > could potentially minimise window usage within it’s scope (any sort of > window > reusing, like mapping whole A16 once to be used with all boards), but this > won’t > work across multiple drivers. Even if all of your drivers are window-wise > economic, > they will still need some amount of windows per each driver. Not that we > have that > many kernel drivers... Yes you can share a window/image between all boards of the same type (in effect we are porting our drivers in this way) *but* it isn't the expected way to work (see Documentation/vme_api.txt struct vme_driver's probe() and match() functions and the GE PIO2 VME driver). Ciao, Alessio -- 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/