On 9/20/2010 11:08 AM, Nori, Sekhar wrote: > Hi Michael, > > On Sat, Sep 18, 2010 at 18:38:13, Michael Williamson wrote: >> >> * I'm not sure I understand why there is a "intr_line" field in the platform >> data and then a possibility to configure an "io_type" as interrupt or polled >> at >> the chip select level. I got burned by setting the "io_type" to >> SPI_IO_TYPE_INTR >> and not setting "intr_line" to non-zero. The probe just hung because it was >> trying to use interrupts but never setting SPILVL register. These fields >> aren't >> mutually exclusive. Is the intent to support a configuration with one chip >> select >> running in polled mode and another in interrupt mode? If so, then it seems >> the SPILVL >> register logic needs some attention during each transfer. > > The intr_line to be set is constant for the SoC. So, irrespective of what the > individual devices on a given board choose to operate (interrupted, polled or > DMA) > the SoC code (da850.c) should setup the intr_line according to how the SPI > interrupt > is wired within the SoC. Can you clarify what you mean by "needs some > attention during > each transfer"? >
Ah... OK. Thank you. I now see that the SPILVL can be INT0 or INT1 for other davinci SoCs like the DM644x. For the da850 (OMAP-L138), SPILVL is valid only for INT1. So pretty much, if your using a da850 (at least), intr_line has to be 1. On other platforms, it carries a lot more meaning... Please ignore my ignorance... Let me know if you want testing on the DMA portion of the patch (when your ready, of course). -Mike _______________________________________________ Davinci-linux-open-source mailing list [email protected] http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
