Assert CS, wait for IRQ, write data sequence

Assert CS, wait for IRQ, write data sequence

[Sergii Kovalchuk]

Hi,

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.


It would be appropriate to assert CS manually, wait for IRQ and then start the 
data transfer, but may be there is some more essential way to accomplish this?

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

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

[Grant Likely]

On Wed, Oct 6, 2010 at 7:49 AM, Sergii Kovalchuk
<sentinelofsetch-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> Hi,
>
> 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.


-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.

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

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

[Sergii Kovalchuk]

On Thursday 07 October 2010 19:36:18 Grant Likely wrote:
> On Wed, Oct 6, 2010 at 7:49 AM, Sergii Kovalchuk
> 
> <sentinelofsetch-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> > Hi,
> > 
> > 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?

Of course, any modifications to generic SPI subsystem are hard to push, but 
this is simple extending and will not break existing functionality. Controller 
drivers may or may not support this initially.

If it will be useful for others and worth implementing.

--
Best regards,
Sergii

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

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

[Jassi Brar]

On Tue, Oct 12, 2010 at 1:22 AM, Sergii Kovalchuk
<sentinelofsetch@gmail.com> 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?

------------------------------------------------------------------------------
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
_______________________________________________
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general

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

[Sergii Kovalchuk]

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.

Thanks,

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

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

[Grant Likely]

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.

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

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

[Sergii Kovalchuk]

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