On Tuesday 12 October 2010 19:34:58 Grant Likely wrote: > On Tue, Oct 12, 2010 at 10:22 AM, Sergii Kovalchuk > > <[email protected]> wrote: > > On Tuesday 12 October 2010 03:51:10 Jassi Brar wrote: > >> On Tue, Oct 12, 2010 at 1:22 AM, Sergii Kovalchuk > >> > >> <[email protected]> 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 _______________________________________________ spi-devel-general mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/spi-devel-general
