Hi!

You were right, there is nothing wrong with the spi transfer.

The problem is the hardware. This chip really needs some delay before
deasserting CS on register writes. Otherwise it just silently ignores
the register write.

I no longer think that anything is wrong with spi communication, i can
reliably read any chip register. The problem only occurs on register
writes, and not even on all registers.

On giveback(), if i add a delay _before_ cs_control(CS_DEASSERT), it works.
If i add it just _after_ cs_control() it does not work.

I see that there is a .delay_usecs field on spi_transfer:

 * @delay_usecs: microseconds to delay after this transfer before
 *      (optionally) changing the chipselect status, then starting
 *      the next transfer or completing this @spi_message.

But it is only called for the previous transfer when on RUNNING_STATE,
so a second spi_transfer is needed on the same spi_message to actually
use this feature.

Should i submit a patch to use this delay_usecs field also on
DONE_STATE, so it actually do something when set on the last
spi_transfer? Or should i just cheat pxa2xx_spi with:

        struct spi_transfer t[2];
        struct spi_message m;

        spi_message_init(&m);
        t[0].len = 4;
        t[0].tx_buf = (u8 *)data;
        t[0].rx_buf = (u8 *)data;
        t[0].bits_per_word = 32;
        t[0].delay_usecs = 300;
        spi_message_add_tail(&t[0], &m);

        /* trick pxa2xx_spi so it uses t[0].delay_usecs */
        t[1].len = 0;
        spi_message_add_tail(&t[1], &m);

        return spi_sync(pcap.spi, &m);

(with the above code my chip works great without changes to pxa2xx_spi.c)

My opinion is that this field should be used to delay also on
DONE_STATE: "microseconds to delay after this transfer before changing
the chipselect status, then starting the next transfer
*or*completing*this*spi_message*"

I will be happy to submit a patch to change this if you think the
delay on DONE_STATE is acceptable.

-- 
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

Reply via email to