Assert CS, wait for IRQ, write data sequence

Sergii Kovalchuk

author

2010-10-06 13:49 UTC #0 lore raw

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

Grant Likely

2010-10-07 16:36 UTC #2 lore raw

In reply to a message not in the archive

Quoted 9 lines · 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

Quoted 6 lines

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.

Signature · 9 lines

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

Sergii Kovalchuk

author

2010-10-11 16:22 UTC #4 lore raw

In reply to a message not in the archive

Quoted 20 lines · On Thursday 07 October 2010 19:36:18 Grant Likely wrote:

On Wed, Oct 6, 2010 at 7:49 AM, Sergii Kovalchuk
Quoted 10 lines · <[email protected]> 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
Quoted 6 lines
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.

Quoted 6 lines

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

Jassi Brar

2010-10-12 00:51 UTC #6 lore raw

In reply to a message not in the archive

Quoted 25 lines · Sergii Kovalchuk

Quoted 17 lines · On Thursday 07 October 2010 19:36:18 Grant Likely wrote:
On Wed, Oct 6, 2010 at 7:49 AM, Sergii Kovalchuk
Quoted 9 lines
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
Quoted 6 lines
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.
Quoted 6 lines
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.

Quoted 7 lines

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 [email protected]
https://lists.sourceforge.net/lists/listinfo/spi-devel-general

Sergii Kovalchuk

author

2010-10-12 16:22 UTC #8 lore raw

In reply to a message not in the archive

Quoted 37 lines · On Tuesday 12 October 2010 03:51:10 Jassi Brar wrote:

On Tue, Oct 12, 2010 at 1:22 AM, Sergii Kovalchuk
Quoted 26 lines · <[email protected]> wrote:
Quoted 18 lines · On Thursday 07 October 2010 19:36:18 Grant Likely wrote:
On Wed, Oct 6, 2010 at 7:49 AM, Sergii Kovalchuk
Quoted 8 lines
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
Quoted 7 lines
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.
Quoted 6 lines
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.
Quoted 7 lines
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?

Quoted 6 lines

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

Grant Likely

2010-10-12 16:34 UTC #10 lore raw

In reply to a message not in the archive

Quoted 45 lines · Sergii Kovalchuk

Quoted 37 lines · On Tuesday 12 October 2010 03:51:10 Jassi Brar wrote:
On Tue, Oct 12, 2010 at 1:22 AM, Sergii Kovalchuk
Quoted 26 lines · <[email protected]> wrote:
Quoted 18 lines · On Thursday 07 October 2010 19:36:18 Grant Likely wrote:
On Wed, Oct 6, 2010 at 7:49 AM, Sergii Kovalchuk
Quoted 8 lines
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
Quoted 7 lines
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.
Quoted 6 lines
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.
Quoted 7 lines
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?
Quoted 6 lines
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?

Quoted 5 lines

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

Sergii Kovalchuk

author

2010-10-12 17:29 UTC #12 lore raw

In reply to a message not in the archive

Quoted 65 lines · On Tuesday 12 October 2010 19:34:58 Grant Likely wrote:

On Tue, Oct 12, 2010 at 10:22 AM, Sergii Kovalchuk
Quoted 46 lines · <[email protected]> wrote:
Quoted 38 lines · On Tuesday 12 October 2010 03:51:10 Jassi Brar wrote:
On Tue, Oct 12, 2010 at 1:22 AM, Sergii Kovalchuk
Quoted 27 lines · <[email protected]> wrote:
Quoted 18 lines · On Thursday 07 October 2010 19:36:18 Grant Likely wrote:
On Wed, Oct 6, 2010 at 7:49 AM, Sergii Kovalchuk
Quoted 8 lines
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
Quoted 7 lines
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.
Quoted 7 lines
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.
Quoted 7 lines
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?
Quoted 6 lines
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?
Quoted 6 lines
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.

Quoted 1 line

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