From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27576 invoked by alias); 15 Sep 2009 12:09:13 -0000 Received: (qmail 27567 invoked by uid 22791); 15 Sep 2009 12:09:12 -0000 X-SWARE-Spam-Status: No, hits=-2.3 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: sourceware.org Received: from anika.2020media.com (HELO smtp.2020smtp.net) (212.124.192.214) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 15 Sep 2009 12:09:07 +0000 Received: from [212.124.199.38] (helo=hercules.zynaptic.com) by smtp.2020smtp.net with esmtp (Exim 4.63) (envelope-from ) id 1MnWpy-0003pz-4T; Tue, 15 Sep 2009 13:08:46 +0100 Received: from [127.0.0.1] (localhost [127.0.0.1]) by hercules.zynaptic.com (Postfix) with ESMTPA id 286F43FA60; Tue, 15 Sep 2009 13:08:39 +0100 (BST) Message-ID: <4AAF83BF.5060304@zynaptic.com> Date: Tue, 15 Sep 2009 12:09:00 -0000 From: Chris Holgate User-Agent: Thunderbird 2.0.0.22 (X11/20090605) MIME-Version: 1.0 To: Stanislav Meduna CC: eCos Discussion References: <4AAF766C.9070101@meduna.org> In-Reply-To: <4AAF766C.9070101@meduna.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact ecos-discuss-help@ecos.sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: ecos-discuss-owner@ecos.sourceware.org Subject: Re: [ECOS] I/O thread safety X-SW-Source: 2009-09/txt/msg00111.txt.bz2 Stanislav Meduna wrote: > Hi, > > I'd like to ask whether and how is the thread-safety > of the I/O subsystem approached - is this a problem > of application code, each subsystem, each driver,...? > > I am implementing a driver for a CAN controller > connected via a SPI interface. Each CAN controller > transaction requires a few separate SPI transactions > that should not be interrupted by transactions done > from another thread (this can be probably fixed > to do everything in one SPI transaction, but > I'd like to ask anyway). The generic SPI layer has a mutex which protects the bus between calls to cyg_spi_transaction_begin and cyg_spi_transaction_end, so you can assemble an atomic series of SPI transfers fairly easily. You can either hold the chip select for the device for the duration of the entire transaction or use the 'drop_cs' parameter in cyg_spi_transaction_transfer in order to release the chip select between transfers. Of course this assumes that you're accessing the SPI API from thread context and not DSR handlers from the CAN driver. Chris. -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss