2008-12-04 20:37:18     about spi_bfin5xx.c(li yi)

2008-12-04 20:37:18     about spi_bfin5xx.c(li yi)

dillon hua (CHINA)

Message: 66363   

hi ,li yi:

  from your spi_bfin5xx.c , i find all the bfin_spi_**_writer and bfin_spi_**_cs_chg_writer function, you check the RXS bit of spi state register for spi transfer complete, and give a annotate

"/* wait until transfer finished.

     checking SPIF or TXS may not guarantee transfer completion */"

can you give me a detail explaination ?

but from the bfin_spi_pump_transfers,line 860

/* we always use SPI_WRITE mode. SPI_READ mode

     seems to have problems with setting up the

     output value in TDBR prior to the transfer. */

  write_CTRL(drv_data, (cr | CFG_SPI_WRITE));

so,if you use CFG_SPI_WRITE , maybe you should check TXS and SPIF bit . or there are some mistake inside bf5xx chipset ?

thank you !

-dillon

QuoteReplyEditDelete

2008-12-04 22:40:28     Re: about spi_bfin5xx.c(li yi)

Yi Li (CHINA)

Message: 66368   

There is relationship between RXS, TXS, and SPIF with regarding to time sequence, as Wolfgang noted (and as I understand), when doing a transmit,usually TXS is cleared first, then RXS set, then SPIF set, but when spi_baud < 4, SPIF is set before RXS is set. So the safe way to make sure a transimit is finished is, doing transmit in duplex mode (in fact every SPI transfer is duplex physically, either receive or transmit), wait for RXS set (meaning RDBR is full, and we don't worry that this transfer will affect next transfer). For details, please read: http://www.mail-archive.com/uclinux-dist-devel@blackfin.uclinux.org/msg01049.html//www.mail-archive.com/uclinux-dist-devel@blackfin.uclinux.org/msg01049.html

-Yi

QuoteReplyEditDelete

2008-12-05 12:35:14     Re: about spi_bfin5xx.c(li yi)

dillon hua (CHINA)

Message: 66419   

hi li yi:

   thanks for your help, now my wifi problem has been resolved, i must close the d-cache, if not, i can't send out the right data to marvell's gspi8686 by spi dma.

  i just find the result, but i don't know the cause,why ?

-dillon

QuoteReplyEditDelete

2008-12-09 10:10:40     Re: about spi_bfin5xx.c(li yi)

Yi Li (CHINA)

Message: 66570   

Dillon,

This is interesting. The caches for transmit buffer is supposed to be flushed in spi_bf5xx.c when doing DMA transmit.

-Yi

QuoteReplyEditDelete

2008-12-09 10:29:10     Re: about spi_bfin5xx.c(li yi)

Wolfgang Muees (GERMANY)

Message: 66572   

Yi,

you wrote:

This is interesting. The caches for transmit buffer is supposed to be flushed in spi_bf5xx.c when doing DMA transmit.

I have checked. You are right.

But who does the ssync to drain the write buffer of the core?

I think this is missing....

regards

Wolfgang

TranslateQuoteReplyEditDelete

2008-12-09 10:37:05     Re: about spi_bfin5xx.c(li yi)

Mike Frysinger (UNITED STATES)

Message: 66573   

the write buffer is drained automatically.  SSYNC just returns after all commits to the system have taken place.  we dont use SSYNC's unless actually necessary.

QuoteReplyEditDelete

2008-12-09 19:46:15     Re: about spi_bfin5xx.c(li yi)

dillon hua (CHINA)

Message: 66579   

hi li yi:

   we have not use the spi_bf5xx.c now , but we will have gspi8686 and sd card connect to host by the same spi bus,so we will use spi_bf5xx.c next time.

   and the really reason for d-cache must be closed ,is not flush the dcache before dma read  data from sdram,so ,there might some difference between cache and sdram, we use the "blackfin_dcache_flush_range" to fix this problem

   we just found "blackfin_dcache_flush_range" and "blackfin_dcache_invalidate_range" have been used in dma_memcpy dma_insb dma_outsb , etc but , spi_bf5xx.c have not use these function, also , spi_bf5xx.c have not use the blackfin_dcache_flush_range and blackfin_dcache_invalidate_range, so , maybe spi_bf5xx.c have not do the flush work ?

   by the way,we have tested transfer D1 video by wifi to pc, the image is very clear ,better than dm9000

QuoteReplyEditDelete

2008-12-09 20:30:49     Re: about spi_bfin5xx.c(li yi)

Yi Li (CHINA)

Message: 66580   

Dillon,

"we have not use the spi_bf5xx.c now , but we will have gspi8686 and sd card connect to host by the same spi bus,so we will use spi_bf5xx.c next time."

When using a GPS device with SD/SPI, you may also need the "spi_lock_bus()/spi_unlock_bus()" APIs, otherwise SD may not work properly.

   "we just found "blackfin_dcache_flush_range" and "blackfin_dcache_invalidate_range" have been used in dma_memcpy dma_insb dma_outsb , etc but , spi_bf5xx.c have not use these function, also , spi_bf5xx.c have not use the blackfin_dcache_flush_range and blackfin_dcache_invalidate_range, so , maybe spi_bf5xx.c have not do the flush work ?"

Looking at spi_bf5xx.c in svn trunk, there is:

Before doing DMA transmit:

"

/* flush caches, if needed */

if (bfin_addr_dcachable((unsigned long) drv_data->tx))

        flush_dcache_range((unsigned long) drv_data->tx,

        (unsigned long) (drv_data->tx + drv_data->len_in_bytes));

"

-Yi

QuoteReplyEditDelete

2008-12-09 20:54:01     Re: about spi_bfin5xx.c(li yi)

dillon hua (CHINA)

Message: 66581   

thanks , my code is so old, i will try the new spi_bfin5xx.c

QuoteReplyEditDelete

2008-12-10 09:01:17     Re: about spi_bfin5xx.c(li yi)

Wolfgang Muees (GERMANY)

Message: 66603   

Mike,

you wrote:

the write buffer is drained automatically.

Can you please explain in detail?

In cache.S, I can only see cache flush instructions. Are these cache flush instructions are draining the write buffer?

We are doing some double buffer DMA with sport and I am interested in having it 100% right.

regards

Wolfgang

TranslateQuoteReplyEditDelete

2008-12-10 14:26:29     Re: about spi_bfin5xx.c(li yi)

Mike Frysinger (UNITED STATES)

Message: 66611   

the core itself will drain to the system.  there are very few cases where a csync/ssync is absolutely necessary, and beyond that the only time ssync is needed when cramming a bunch of operations together quickly faster (CCLK speeds) than the system clock.

so where exactly do you think a ssync is needed ?  cache functions do not require ssync's to operate properly.  it is all taken care of in the hardware.

QuoteReplyEditDelete

2008-12-11 05:58:04     Re: about spi_bfin5xx.c(li yi)

Wolfgang Muees (GERMANY)

Message: 66627   

Mike,

I do think about the following situation:

a) CPU is filling a memory block with data. Data cache is writeback.

b) CPU is doing a data cache flush, using one of the functions in cache.S

c) CPU is starting a DMA transfer from the memory block.

d) CPU writebuffer is writing the last bytes of the data block out to memory.

If I understand your statement correctly then d) is done before c). Can you show me how this is enforced in the hardware?

Are all writes done in the same order as they are executed by the CPU? Or is there some write reordering happen inside the write buffer or the CPU?

I can not imagine that each and every flush of a data cache line is flushing the write buffer. This would be a performance problem. Only ssnyc is flushing the write buffer between L1 memory and external memory.

regards

Wolfgang