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

Reply via email to