Re: [PATCH v5 1/1] davinci: spi: replace existing driver

[Michael Williamson <michael.williamson-wZX4cNJlHJ2sVWG7oymsAA@public.gmane.org>]

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