Menu
▾
▴
[Gumstix-users] R: R: SPI repeated messages on Overo
|
From: Federico B. <fed...@da...> - 2010-11-15 14:15:17
|
I think I'm not going DMA because my transfer is only 4 bytes long, so PIO
will be used. I tried setting xfer->rx_buf to NULL buffer but the error is
still here, too many transactions. The oops message is the same as before.
Sorry for the misunderstanding, I did not call complete() in my completion
callback. My completion callback is empty. Please consider in my previous
email "complete == spi completion callback".
For the record, here it is:
static void ltc244x_complete(void *ltc244x_private)
{
/* struct ltc244x_private *ltc_private = ltc244x_private;
struct ltc244x *ltc = ltc_private->ltc244x; */
}
Here is a little dump from my spi sniffer.
Columns are:
Index, Absolute time m:s.ms.us, Duration, length, Error, Record, Data (odd
bytes: MOSI, even bytes: MISO).
5311,0:15.949.133,47.400 us,4 B,,Transaction,010F 0AFF 00FF 00FF
5314,0:15.955.803,47.400 us,4 B,,Transaction,010F 0AFF 00FF 00FF
5317,0:15.962.474,47.600 us,4 B,,Transaction,010F 0AFF 00FF 00FF
5320,0:15.969.135,47.400 us,4 B,,Transaction,010F 0AFF 00FF 00FF
5323,0:15.975.805,47.400 us,4 B,,Transaction,010F 0AFF 00FF 00FF
5326,0:15.982.476,47.400 us,4 B,,Transaction,010F 0AFF 00FF 00FF
5329,0:15.989.137,47.400 us,4 B,,Transaction,010F 0AFF 00FF 00FF
5332,0:15.995.808,47.300 us,4 B,,Transaction,010F 0AFF 00FF 00FF
5335,0:16.002.477,47.400 us,4 B,,Transaction,010F 0AFF 00FF 00FF
5338,0:16.009.138,47.600 us,4 B,,Transaction,010F 0AFF 00FF 00FF
5341,0:16.015.802,47.400 us,4 B,,Transaction,010F 0AFF 00FF 00FF
5344,0:16.022.479,47.700 us,4 B,,Transaction,010F 0AFF 00FF 00FF
5347,0:16.029.142,47.500 us,4 B,,Transaction,010F 0AFF 00FF 00FF
5350,0:16.035.811,47.400 us,4 B,,Transaction,010F 0AFF 00FF 00FF
5353,0:16.042.487,47.500 us,4 B,,Transaction,010F 0AFF 00FF 00FF
5356,0:16.049.149,48.100 us,4 B,,Transaction,010F 0AFF 00FF 00FF
5359,0:16.055.806,47.400 us,4 B,,Transaction,010F 0AFF 00FF 00FF
5362,0:16.062.473,47.600 us,4 B,,Transaction,010F 0AFF 00FF 00FF
5365,0:16.078.964,48.600 us,4 B,,Transaction,010F 0AFF 00FF 00FF
5368,0:16.079.014,47.200 us,4 B,,Transaction,01FF 0AFF 00FF 00FF
5371,0:16.079.062,47.100 us,4 B,,Transaction,01FF 0AFF 00FF 00FF
5374,0:16.079.110,47.100 us,4 B,,Transaction,01FF 0AFF 00FF 00FF
5377,0:16.079.158,47.100 us,4 B,,Transaction,01FF 0AFF 00FF 00FF
5380,0:16.079.206,47.100 us,4 B,,Transaction,01FF 0AFF 00FF 00FF
5383,0:16.079.254,47.100 us,4 B,,Transaction,01FF 0AFF 00FF 00FF
Index is contiguous because every record has 2 subrecords (tx/rx) with
incrementing index. As you can see, from index 5365 the absolute time
increments by about 50us, whereas until 5362 the absolute time increment is
in 6-7ms order. The received message is 0xFFFFFFFF (instead of 0x0FFFFFFF),
because AD is still not ready to send data and puts MISO to high state. The
real presence of the AD is not needed for this issue to happen since I
discard every byte rxed.
The strange thing is the BIG delay between 5362 and 5365... more than 15ms.
>From that point on, messages are sent with no delay, and system is hanged.
After 60 seconds console shows first oops message.
This time only 16 seconds after insmod and the issue showed up.
--
Federico Belvisi
> -----Messaggio originale-----
> Da: ScottEllis [mailto:sco...@gm...]
> Inviato: lunedì 15 novembre 2010 14:32
> A: gum...@li...
> Oggetto: Re: [Gumstix-users] R: SPI repeated messages on Overo
>
>
> It's kind of strange that you saw this in your oops message.
>
> PC is at mcspi_wait_for_reg_bit+0x40/0x58
>
> That function only gets called in omap2_mcspi_txrx_pio() but that only
> gets called if len < DMA_MIN_BYTES
>
> ... omap2_mcspi_work() ...
>
> if (m->is_dma_mapped || t->len >= DMA_MIN_BYTES)
> count = omap2_mcspi_txrx_dma(spi, t);
> else
> count = omap2_mcspi_txrx_pio(spi, t);
> ...
>
> from omap2_mcspi.c
> #define DMA_MIN_BYTES 8
>
> I was going to suggest forcing pio mode transfers instead of dma,
> but it looks like that is already happening. Do you see why?
>
> You could set the message->rx_buff to NULL since that will change
> the behavior of omap2_mcspi_txrx_pio() and then see if your problem
> changes. That will cut about half the code from omap2_mcspi_txrx_pio()
> and maybe start narrowing down the problem.
>
> Otherwise, I don't see anything obvious. I know you usually call the
> kernel's scheduler complete() in a completion callback, but since there
> aren't any threads waiting on your completion, that probably doesn't
> matter. Since it's not working though, maybe that is worth trying too.
> Can't hurt.
>
>
> --
> View this message in context: http://old.nabble.com/SPI-repeated-
> messages-on-Overo-tp30199878p30218881.html
> Sent from the Gumstix mailing list archive at Nabble.com.
>
>
> -----------------------------------------------------------------------
> -------
> Centralized Desktop Delivery: Dell and VMware Reference Architecture
> Simplifying enterprise desktop deployment and management using
> Dell EqualLogic storage and VMware View: A highly scalable, end-to-end
> client virtualization framework. Read more!
> http://p.sf.net/sfu/dell-eql-dev2dev
> _______________________________________________
> gumstix-users mailing list
> gum...@li...
> https://lists.sourceforge.net/lists/listinfo/gumstix-users
|