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
[email protected]
https://lists.sourceforge.net/lists/listinfo/spi-devel-general