On Mon, Aug 18, 2008 at 3:53 PM, Ned Forrester <[EMAIL PROTECTED]> wrote: > Can you be more specific about your problem? If CS is not being > asserted/deasserted at the right times, then that needs to be fixed. > What are you using for CS; this driver only works correctly when a GPIO > pin is assigned for CS, and is controlled with the cs_control() callback.
Yes, I´m using a gpio for CS. cs_control is OK. > The below patch seems to paper over some other problem. > wait_ssp_rx_stall() is used to recover from errors, by flushing and > discarding words from the RX fifo. Also, int_transfer_complete() is > only called from places where we know that all expected characters have > been received and transferred to memory. Not really, something is really wrong with the call to int_transfer_complete. If i replace the wait_ssp_rx_stall() call with a simple printk() call everything works just fine. Same with an udelay(300). I may be wrong, but it seems that interrupt_transfer calls int_transfer_complete after the total amount of data is put on the FIFO, but it does not guarantee that the IO is actually done before calling it. > This patch would "fix" a situation where extra words are in the RX FIFO > after the expected number have been read. If there are more characters > in the FIFO than were transmitted, then that needs to be fixed and not > ignored. > > Can you provide a patch or more information that addresses the > underlying problem? As I already said, i am converting a working driver from ssp.c´s ssp_read_word/ssp_write_word to pxa2xx_spi. The driver works just fine with: gpio_set_value(cs, 0); ssp_write_word(&ssp_dev, data); ssp_read_word(&ssp_dev, &ret); gpio_set_value(cs, 1); After the conversion i ended with this code: static int ezx_pcap_putget(u32 *data) { struct spi_transfer t; struct spi_message m; spi_message_init(&m); t.len = 4; t.tx_buf = (u8 *)data; t.rx_buf = (u8 *)data; t.bits_per_word = 32; spi_message_add_tail(&t, &m); return spi_sync(pcap.spi, &m); } The driver is a for a PMIC, it has 32 25bit registers, which i need to access trough 32bit spi IO. Without the wait_ssp_rx_stall patch (or any other delay before the CS_DEASSERT) this is what i get: pcap_read: reg_num:3 value:00edf48a pcap_write: reg_num:3 value:00123456 pcap_read: reg_num:3 value:00edf48a pcap_read: reg_num:3 value:00edf48a With the patch, or with an udelay(300) call instead of wait_ssp_rx_stall: pcap_read: reg_num:3 value:00edf48a pcap_write: reg_num:3 value:00123456 pcap_read: reg_num:3 value:00123456 pcap_read: reg_num:3 value:00123456 Since the udelay(300) call works, and it doesnt touch the ssp registers, it looks like int_transfer_complete is being called before it should. -- Daniel Ribeiro ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ spi-devel-general mailing list spi-devel-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/spi-devel-general