Subject: Re: [spi-devel-general] Re: [PATCH 2.6-git 0/4] SPI core refresh
From: Rui Sousa <rui.sousa@laposte.net>
To: Vitaly Wool <vwool@ru.mvista.com>
Cc: dmitry pervushin <dpervushin@gmail.com>,
       Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
       David Brownell <david-b@pacbell.net>, basicmark@yahoo.com,
       komal_shah802003@yahoo.com, stephen@streetfiresound.com,
       spi-devel-general@lists.sourceforge.net, Joachim_Jaeger@digi.com
In-Reply-To: <439FC259.60103@ru.mvista.com>
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>
	 <439FC259.60103@ru.mvista.com>
Content-Type: text/plain
Date: Wed, 14 Dec 2005 15:28:05 +0100
Message-Id: <1134570485.26799.17.camel@localhost.localdomain>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 2741
Lines: 93

On Wed, 2005-12-14 at 09:57 +0300, Vitaly Wool wrote:
> 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.

This is what I'm doing now (sync + PIO). In any case the SPI bus
controller I'm using only supports PIO.

> 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).

The main problem is that just to be able to ack the interrupt I need to
write on the SPI bus. So now I need to (1) modify my GPIO interrupt
handler so that it let's me exit before acking the interrupt on the
device (2) no longer share this GPIO with other devices interrupts...

It's possible to use the proposed API, it's just that in my case it will
increase the SPI slave driver complexity.

> Vitaly

Rui

> 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/