On Wed, Nov 10, 2010 at 9:41 AM, Gregory CLEMENT <gregory.clement@xxxxxxxxxxxxxxxxxx> wrote: > On 11/10/2010 04:57 PM, Grant Likely wrote: >> >> On Wed, Nov 10, 2010 at 11:32:59AM +0100, Gregory CLEMENT wrote: >>> >>> When SPI wake up from OFF mode, CS is in the wrong state: force it >>> to the inactive state. >>> >>> During the system life, I monitored the CS behavior using a >>> oscilloscope. I also activated debug in omap2_mcspi, so I saw when >>> driver disable the clocks and restore context when device is not >>> used. >>> Each time the CS was in the correct state. >>> It was only when system was put suspend to ram with off-mode >>> activated that on resume the CS was in wrong state( ie activated). >> >> Sounds like a bug in the suspend/resume path of the spi_master, not >> the spi_device. Trying to work around it via the spi_device resume >> path is the wrong approach. >> > > OK it was not clear to me that spi_resume() and spi_suspend() were specifics > to devices as these functions belong to a bus structure. > > So you suggest to use the suspend/resume functions of the platform_driver > structure of omap2_mcspi_driver, right? correct. g. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
