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.
g.
>
> Signed-off-by: Gregory CLEMENT <gregory.clement@xxxxxxxxxxxxxxxxxx>
> ---
> drivers/spi/omap2_mcspi.c | 10 ++++++++++
> 1 files changed, 10 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/spi/omap2_mcspi.c b/drivers/spi/omap2_mcspi.c
> index 2a651e6..938f14c 100644
> --- a/drivers/spi/omap2_mcspi.c
> +++ b/drivers/spi/omap2_mcspi.c
> @@ -1139,6 +1139,15 @@ static u8 __initdata spi4_txdma_id[] = {
> };
> #endif
> +/* When SPI wake up, CS is in wrong state: force it to unactive state*/
> +static void omap2_mcspi_resume(struct spi_device *spi)
> +{
> + omap2_mcspi_enable_clocks( spi_master_get_devdata(spi->master));
> + /* We need to togle CS state for OMAP take this chang in account*/
> + omap2_mcspi_force_cs(spi, 1);
> + omap2_mcspi_force_cs(spi, 0);
> + omap2_mcspi_disable_clocks( spi_master_get_devdata(spi->master));
> +}
> static int __init omap2_mcspi_probe(struct platform_device *pdev)
> {
> struct spi_master *master;
> @@ -1194,6 +1203,7 @@ static int __init omap2_mcspi_probe(struct
> platform_device *pdev)
> master->transfer = omap2_mcspi_transfer;
> master->cleanup = omap2_mcspi_cleanup;
> master->num_chipselect = num_chipselect;
> + master->resume = omap2_mcspi_resume;
> dev_set_drvdata(&pdev->dev, master);
> -- 1.7.0.4
>
--
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
