Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751281AbVLNG5o (ORCPT ); Wed, 14 Dec 2005 01:57:44 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751282AbVLNG5o (ORCPT ); Wed, 14 Dec 2005 01:57:44 -0500 Received: from rtsoft3.corbina.net ([85.21.88.6]:6763 "EHLO buildserver.ru.mvista.com") by vger.kernel.org with ESMTP id S1751281AbVLNG5o (ORCPT ); Wed, 14 Dec 2005 01:57:44 -0500 Message-ID: <439FC259.60103@ru.mvista.com> Date: Wed, 14 Dec 2005 09:57:29 +0300 From: Vitaly Wool User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Rui Sousa CC: dmitry pervushin , Linux Kernel Mailing List , David Brownell , basicmark@yahoo.com, komal_shah802003@yahoo.com, stephen@streetfiresound.com, spi-devel-general@lists.sourceforge.net, Joachim_Jaeger@digi.com Subject: Re: [spi-devel-general] Re: [PATCH 2.6-git 0/4] SPI core refresh References: <20051212182026.4e393d5a.vwool@ru.mvista.com> <1134410498.12925.8.camel@localhost.localdomain> <1134475765.1590.2.camel@fj-laptop> <1134486683.10394.7.camel@localhost.localdomain> In-Reply-To: <1134486683.10394.7.camel@localhost.localdomain> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2040 Lines: 76 Looks like we'll have to remove explicit wait_for_completion from spi_trasnfer to make it (potentially) work. Rui, your turn will then be a) not to use thread async message handling which is the default but b) use some kind of PIO method for reading from the SPI bus. The other solution which looks preferable to me is to have a pretty simple interrupt handler which just wakes up a thread which in turn reads what it wants not caring much about sleeps (as it's not gonna be interrupt context any more). Vitaly Rui Sousa wrote: >On Tue, 2005-12-13 at 15:09 +0300, dmitry pervushin wrote: > > >>On Mon, 2005-12-12 at 19:01 +0100, Rui Sousa wrote: >> >> >>>How do you handle IRQ's generated by a SPI device (e.g ack the >>>interrupt, check if it was the SPI device that generated the >>>interrupt, ...) if you can't read/write on the SPI bus from interrupt >>>context? >>> >>> >>Hmm... what do you mean by "cannot read/write" ? Normally you can >>write/read registers in interrupt context >> >> > >The registers I want to read are from a SPI device (a SPI slave attached >to a SPI bus). I need to use SPI bus transfers to access them. > > > >>, and then set the >>flag/complete the completion/what else ? >> >> > >If I read the API correctly reading/writing a byte from the SPI bus >(synchronously) always implies putting the task doing the read to sleep: > >int spi_transfer(struct spi_msg *msg, void (*callback) (struct spi_msg >*, int)) >{ > >... > err = TO_SPI_BUS_DRIVER(bus->driver)->queue(msg); > wait_for_completion(&msg->sync); >... >} > >So, how can I, from an interrupt handler, read/write a couple of bytes >from my SPI device using this API? > > > >>In other words, could you please share the code that causes problems ? >> >> >> > >Rui > > > > - 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/