Re: Assert CS, wait for IRQ, write data sequence

[Sergii Kovalchuk <sentinelofsetch-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>]

On Tuesday 12 October 2010 19:34:58 Grant Likely wrote:
> On Tue, Oct 12, 2010 at 10:22 AM, Sergii Kovalchuk
> 
> <sentinelofsetch-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> > On Tuesday 12 October 2010 03:51:10 Jassi Brar wrote:
> >> On Tue, Oct 12, 2010 at 1:22 AM, Sergii Kovalchuk
> >> 
> >> <sentinelofsetch-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> >> > On Thursday 07 October 2010 19:36:18 Grant Likely wrote:
> >> >> On Wed, Oct 6, 2010 at 7:49 AM, Sergii Kovalchuk
> >> >> 
> >> >> > I'm implementing an SPI protocol driver for TI WL12xx combo chip.
> >> >> > According to the spec, for write transaction I should complete the
> >> >> > following sequence:
> >> >> > 
> >> >> > 1. Assert CS
> >> >> > 2. Wait until chip will trigger IRQ
> >> >> > 3. Write data
> >> >> > 
> >> >> > Looking at spi_transfer structure I wondering, how I can implement
> >> >> > such logic - there is no explicit ways to implement "wait for an
> >> >> > event" within single spi_message processing.
> >> >> > 
> >> >> > As current workarround I use a simple delay in 5 us, but for sleep
> >> >> > states it might be not sufficient, since wake-up time are ususally
> >> >> > greater.
> >> >> 
> >> >> Wow.  That's nasty.  The SPI layer really doesn't have a mechanism
> >> >> for handling that.  What you *could* do is lock the spi bus; assert
> >> >> CS manually; wait for the irq, and then issue the transfer.  Not
> >> >> exactly pretty, but it would work within the existing
> >> >> infrastructure.
> >> >> 
> >> >> g.
> >> > 
> >> > Yes, seems to be nasty. This is what I'm doing now - locking the bus
> >> > and waiting for IRQ, but this is really ugly. Just wondered, if there
> >> > is some hidden way.
> >> > 
> >> > Not sure, if it more or less common situation. If so, may be it will
> >> > be worth to extend spi_tranfer to handle "timed wait for IRQ/event"
> >> > in some kind of busy loop or completion - depending of context?
> >> 
> >> By constraints of your bus controller, you can't possibly do anything
> >> more useful than
> >> waiting 'decently'. After all, only one CS can be active at any time
> >> on the bus and
> >> your h/w expects that while it prepares to send/recv data.
> >> Or am I being naive?
> > 
> > Almost certainly, there is no way to do something more useful. If I can
> > manually assert CS (and prevent controller from serving others), then
> > wait for IRQ, continue transfer and manually deassert CS (and unlock
> > controller) - it will work. But this moves some controller functionality
> > into protocol layer and probably needs some "improuvements" into
> > controller driver - to lock it.
> 
> There is a new API for exclusively locking the SPI bus.  Search for
> spi_bus_lock and spi_bus_unlock in Linus' current tree.  It should do
> what you need.  You'll still need to manually assert CS, and make sure
> that CS doesn't toggle when the transfer is initiated, but otherwise
> it should be good.  The best thing might be to manage the CS as a
> simple gpio under the control of your driver and not let the bus touch
> it at all.  As long as your driver holds the bus lock it should all be
> okay.
> 
> g.

Thanks, I will look into it. Probably this is good answer on all these 
questions, at least temporary.

--
Best regards,
Sergii Kovalchuk

------------------------------------------------------------------------------
Beautiful is writing same markup. Internet Explorer 9 supports
standards for HTML5, CSS3, SVG 1.1,  ECMAScript5, and DOM L2 & L3.
Spend less time writing and  rewriting code and more time creating great
experiences on the web. Be a part of the beta today.
http://p.sf.net/sfu/beautyoftheweb