LinuxPPC-Dev Archive on lore.kernel.org
 help / color / mirror / Atom feed
* 8xx spi completion sometime doesn't generate an interrupt
@ 2006-06-02 15:08 Antonio Di Bacco
  2006-06-02 20:45 ` Wolfgang Denk
  0 siblings, 1 reply; 4+ messages in thread
From: Antonio Di Bacco @ 2006-06-02 15:08 UTC (permalink / raw)
  To: linuxppc-embedded

As far I understood the spi bus device of mpc8xx works independently from the 
attached device (in my case a dataflash m25pe80). Thus I don't understand why 
sometime when I start an SPI transfer I don't receive an interrupt for the 
completion of this operation. I wait 50 ms for this interrupt and sometime it 
doesn't happen. Anyone had a similar problem?

Bye,
Antonio.

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: 8xx spi completion sometime doesn't generate an interrupt
  2006-06-02 15:08 8xx spi completion sometime doesn't generate an interrupt Antonio Di Bacco
@ 2006-06-02 20:45 ` Wolfgang Denk
  2006-06-02 22:21   ` Antonio Di Bacco
  0 siblings, 1 reply; 4+ messages in thread
From: Wolfgang Denk @ 2006-06-02 20:45 UTC (permalink / raw)
  To: Antonio Di Bacco; +Cc: linuxppc-embedded

In message <200606021708.48814.antonio.dibacco@aruba.it> you wrote:
> As far I understood the spi bus device of mpc8xx works independently from the 
> attached device (in my case a dataflash m25pe80). Thus I don't understand why 
> sometime when I start an SPI transfer I don't receive an interrupt for the 
> completion of this operation. I wait 50 ms for this interrupt and sometime it 
> doesn't happen. Anyone had a similar problem?

Yes, this is known problem, especially if you are runnign the SPI bus
with higher data transfer rates and/or high CPM load. Check  the  FSL
knowledge base; it contains pretty clear statements about what SPI is
*not*  designed  for  - especially, it was not designed for any high-
bandwidth data transfers.

See for example  FAQ-8992:

        The physical clocking speed of the SPI can be up to 12 MHz.
        However, it only has a 16-bit holding register. Thus, the 12
        Mbit/sec rate can only be sustained for 16 bits. If you need
        to transmit more than 2-bytes of data at that clocking rate,
        you must put the data into separate BDs and set the data
        length to 2 and set the L bit in each BD. If you are using a
        character length of 16-bits, the maximum clocking rate is 3.1
        Mbit/sec. If you are using a character length of 8 bits, the
        maximum is 500 Kbits/sec. Note that 500 Kbits/sec is the
        maximum throughput when no other peripherals (SCCs, SMCs) are
        being used. Load on those peripherals will further reduce the
        maximum data rate through the SPI. See the question in the
        SCC area related to maximum data rate calculations.

 
Ok, this was for a 25 MHz (?) 68360 so you get somewhat better  rates
with an 8xx at higher CPU/CPM clocks - but the problem is essentially
still present.

See also FAQ-10566. And especially FAQ-10335, which comes to a point:

        The SPI data rate is based upon the load of the CPM. The SPI
        was not designed to be a high-bandwidth channel. It can run
	    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
        very quickly for bursts of up to 16-bits. But the peripheral
        has no FIFO and low priority in the MPC860 and thus you
        cannot burst lots of data quickly through the interface.


Been there before, and yes, we've been bitten, too. No way to fix.

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
In a business, marketroids, salespukes, and  lawyers  have  different
goals from those who actually do work and produce something. Usually,
is  is the former who triumph over the latter, due to the simple rule
that those who print the money make the rules.
         -- Tom Christiansen in <5jdcls$b04$2@csnews.cs.colorado.edu>

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: 8xx spi completion sometime doesn't generate an interrupt
  2006-06-02 20:45 ` Wolfgang Denk
@ 2006-06-02 22:21   ` Antonio Di Bacco
  2006-06-03  0:51     ` Wolfgang Denk
  0 siblings, 1 reply; 4+ messages in thread
From: Antonio Di Bacco @ 2006-06-02 22:21 UTC (permalink / raw)
  To: Wolfgang Denk; +Cc: linuxppc-embedded

> Yes, this is known problem, especially if you are runnign the SPI bus
> with higher data transfer rates and/or high CPM load ....

I lowered the SPI bus frequency, the interrupt is now always happening but I 
have always problems.
I did further investigations, I'm doing spi transfers of 256 bytes both 
writing and reading (256 is the size of a page of the chip). I write one time 
and then read two times the complete 8Mbit chip. The two reading give me 
always the same result, then, the writing is failing in my case. Probably I 
have to double check the writing procedure. But it is also worth to note that 
changing the PM (prescaler module) and lowering the SPI clock even more the 
writing problem is happening less frequently. 

Thank you,
Bye,
Antonio.

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: 8xx spi completion sometime doesn't generate an interrupt
  2006-06-02 22:21   ` Antonio Di Bacco
@ 2006-06-03  0:51     ` Wolfgang Denk
  0 siblings, 0 replies; 4+ messages in thread
From: Wolfgang Denk @ 2006-06-03  0:51 UTC (permalink / raw)
  To: Antonio Di Bacco; +Cc: linuxppc-embedded

In message <200606030021.58892.antonio.dibacco@aruba.it> you wrote:
>
> I lowered the SPI bus frequency, the interrupt is now always happening but I 
> have always problems.

Try reducing the CPM load. If you have a serial  console  on  a  SMC,
shut it off, etc. Then try again (usually it will be better).

> have to double check the writing procedure. But it is also worth to note that 
> changing the PM (prescaler module) and lowering the SPI clock even more the 
> writing problem is happening less frequently. 

Yeah. At a SPI clock of 0 no errors will happen. The problem is, that
this is not too much useful either ;-)

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
Contrary to popular belief, thinking does not cause brain damage.

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2006-06-03  0:51 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2006-06-02 15:08 8xx spi completion sometime doesn't generate an interrupt Antonio Di Bacco
2006-06-02 20:45 ` Wolfgang Denk
2006-06-02 22:21   ` Antonio Di Bacco
2006-06-03  0:51     ` Wolfgang Denk

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox