From mboxrd@z Thu Jan 1 00:00:00 1970 From: Grant Likely Subject: Re: [PATCH 1/5] spi: spi_lock_bus and spi_unlock_bus Date: Wed, 17 Feb 2010 07:12:02 -0700 Message-ID: References: <20100216204450.e043eed8.eschwab@online.de> <20100216205720.ebe949a1.eschwab@online.de> <552DB282258F46CE995A09EF352B1094@pces> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Cc: David Brownell , vapier-aBrp7R+bbdUdnm+yROfE0A@public.gmane.org, spi-devel-general-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org, yi.li-OyLXuOCK7orQT0dZR+AlfA@public.gmane.org To: Ernst Schwab Return-path: In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: spi-devel-general-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org List-Id: linux-spi.vger.kernel.org On Wed, Feb 17, 2010 at 6:30 AM, Grant Likely w= rote: > On Wed, Feb 17, 2010 at 12:35 AM, Ernst Schwab wro= te: >> Grant Likely wrote: >> >>> It sounds like you're very worried about making changes to the core >>> code, >> >> Maybe... >> >>> In fact, now that I've had an evening to think about it, the solution >>> is even simpler than what I said earlier. =A0It requires 3 things to be >>> added to struct spi_master. >>> - 1 Mutex >>> - 1 spin lock >>> - 1 flag. >> >>> The mutex protects spi_async, and provides sleeping "for free" >>> The spinlock protects the atomic spi_sync call. >> >> Sound viable and good, but, in Documentation/spi/spi-summary we have: >> >> " >> The basic I/O primitive is spi_async(). =A0Async requests may be >> issued in any context (irq handler, task, etc) and completion >> is reported using a callback provided with the message. >> After any detected error, the chip is deselected and processing >> of that spi_message is aborted. >> " >> >> Is this compatible with a Mutex protecting spi_async? >> It seems to me, that spi_async must queue the SPI message >> immediately and return. The queue is implemented in the SPI master drive= r. I >> suppose that's why the blackfin bus locking pioneers chose to make the >> change in the SPI master driver. > > No, sorry, I made a mistake and got the functions backwards when I was > writing up my description. =A0What I meant to say is: > > spi_sync() is protected by a mutex because it can sleep > spi_async() needs to be protected with a flag and a spinlock because > it can be called atomically and must not sleep On that note, apparently I find sync/async easy to mix up. I wonder if other people find the same and if it would be a good idea to migrate to clearer names. Perhaps spi_submit() and spi_submit_atomic(). g. ---------------------------------------------------------------------------= --- SOLARIS 10 is the OS for Data Centers - provides features such as DTrace, Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW http://p.sf.net/sfu/solaris-dev2dev