Re: p54spi (STLC4560) with Marvel XScale CPU (kernel 2.6.25.4)

[Christian Lamparter <chunkeey@googlemail.com>]

On Wednesday 22 September 2010 14:01:46 Alex Mihaylov wrote:
> 2010/9/22 Christian Lamparter <chunkeey@googlemail.com>:
> > their GPL driver looks funny. (Max, it's really worth a look)
> > anyway found this:
> >        /*
> >           Sequence taken from STLC4560 DataSheet
> >           This sequence can be run with the maximum SPI clock frequency (that is, 48 MHz).
> >           1. Power up.
> >           2. Wait 240 ms.
> >           3. Halt processor (EHostDeviceCntrl2 = KSetHostOverride | KSetHostCPUEn=0).
> >           4. Wait 1 us.
> >           5. Enable DMA TX (EHostDmaTxCntrl, KDmaTxCntrlEnable).
> >           6. Write DMA TX length (EHostDmaTxLength).
> >           7. Write DMA TX base (EHostDmaTxBase1).
> >           8. Wait 1 ìs.
> >           9. Write firmware image (EHostDmaData).
> >           10. RAM reset (EHostDeviceCntrl2 = KSetHostOverride | KSetHostReset | KSetRamBoot).
> >           11. Wait 40 ms.
> >           12. RAM boot (EHostDeviceCntrl2 = KSetHostOverride | KSetRamBoot),
> >           13. Enable host interrupts (EHostIntEnable1 = KIrqReady | KIrqWrReady | KHwUpdate | KSwUpdate).
> >           14. Wait for the READY interrupt (100 ms timeout).
> >           15. Acknowledge the READY interrupt.
> >           16. Issue the SLEEP interrupt.
> >         */
> >
> > maybe it helps
> 
> Yes. I see this code. But in p54spi.c I found sequence from 1 to 13.
> Sagrad make this steps with disabler interrupt from card (poll chip
> register). But p54spi wait hardware READY IRQ from chip in 14 (and in
> IRQ routine send acknowledge from 15).

why polling? They even say "14. Wait for the READY interrupt".

Have you checked if the module parameters for power + irq are correct?

static int p54spi_gpio_power = 97;
MODULE_PARM_DESC(p54spi_gpio_power, "gpio number for power line");

static int p54spi_gpio_irq = 87;
MODULE_PARM_DESC(p54spi_gpio_irq, "gpio number for irq line");

Also, on power_on the driver currently waits just 10 and not 240 ms,
maybe this could just be the problem...