[PATCH 0/2] Put OMAP2 SPI CS in unactive state when return from suspend

[PATCH 0/2] Put OMAP2 SPI CS in unactive state when return from suspend

[Gregory CLEMENT]

We notice that when system wake up from OFF mode, then CS is in
unactive state until the first SPI transfert.
For our design it lead to some conflict on this I/O.
Unactive state for CS when there is no transfert shoudl be the correct
behaviour: this is the purpose of these patches.

Gregory CLEMENT (2):
  spi: Add hook on suspend/resume for spi master
  spi/omap2_mcspi: When SPI wake up from OFF mode, CS is in wrong
    state: force it to unactive state

 drivers/spi/omap2_mcspi.c |   11 ++++++++++-
 drivers/spi/spi.c         |   15 ++++++++++++++-
 include/linux/spi/spi.h   |    4 +++-
 3 files changed, 27 insertions(+), 3 deletions(-)

Re: [PATCH 0/2] Put OMAP2 SPI CS in unactive state when return from suspend

[Kevin Hilman]

Gregory CLEMENT <gclement00@gmail.com> writes:

> We notice that when system wake up from OFF mode, then CS is in
> unactive state until the first SPI transfert.
> For our design it lead to some conflict on this I/O.
> Unactive state for CS when there is no transfert shoudl be the correct
> behaviour: this is the purpose of these patches.

This approach handles an off-mode transition during suspend, but if
off-mode is enabled, you can also have an off-mode transition during
idle.

Since you didn't describe what the conflicts you're seeing are, I would
assume that you'll have the same problems in idle as in suspend, and
this series doesn't address the idle case.

Kevin



> Gregory CLEMENT (2):
>   spi: Add hook on suspend/resume for spi master
>   spi/omap2_mcspi: When SPI wake up from OFF mode, CS is in wrong
>     state: force it to unactive state
>
>  drivers/spi/omap2_mcspi.c |   11 ++++++++++-
>  drivers/spi/spi.c         |   15 ++++++++++++++-
>  include/linux/spi/spi.h   |    4 +++-
>  3 files changed, 27 insertions(+), 3 deletions(-)
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 0/2] Put OMAP2 SPI CS in unactive state when return from suspend

[Gregory CLEMENT]

2010/8/11 Kevin Hilman <khilman-1D3HCaltpLuhEniVeURVKkEOCMrvLtNR@public.gmane.org>

> Gregory CLEMENT <gclement00-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> writes:
>
> > We notice that when system wake up from OFF mode, then CS is in
> > unactive state until the first SPI transfert.
> > For our design it lead to some conflict on this I/O.
> > Unactive state for CS when there is no transfert shoudl be the correct
> > behaviour: this is the purpose of these patches.
>
> This approach handles an off-mode transition during suspend, but if
> off-mode is enabled, you can also have an off-mode transition during
> idle.
>
>
Well maybe I didn't use the correct words.
During the system life, I monitored the CS behaviour using a oscilloscope.
I also activate debug in omap2_mcspi, so I see when driver disable the
clocks and restore context when device is not used.
Each time the CS is in the correct state. It is only when there is a suspend
with the following configuration that on resume the CS is in wrong state( ie
activated)


echo 1 > /mnt/pm_debug/enable_off_mode
echo 0 > /mnt/pm_debug/core_pwrdm/suspend
echo 1 > /mnt/pm_debug/voltage_off_while_idle



> Since you didn't describe what the conflicts you're seeing are, I would
> assume that you'll have the same problems in idle as in suspend, and
> this series doesn't address the idle case.
>

I didn't see any problem in idle case, just when system resume from a
suspend to ram (echo mem > /sys/power/state)


>
> Kevin
>
>
>
> > Gregory CLEMENT (2):
> >   spi: Add hook on suspend/resume for spi master
> >   spi/omap2_mcspi: When SPI wake up from OFF mode, CS is in wrong
> >     state: force it to unactive state
> >
> >  drivers/spi/omap2_mcspi.c |   11 ++++++++++-
> >  drivers/spi/spi.c         |   15 ++++++++++++++-
> >  include/linux/spi/spi.h   |    4 +++-
> >  3 files changed, 27 insertions(+), 3 deletions(-)
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> > the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
>



-- 
Gregory CLEMENT
------------------------------------------------------------------------------
This SF.net email is sponsored by 

Make an app they can't live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev 

Re: [PATCH 0/2] Put OMAP2 SPI CS in unactive state when return from suspend

[Gregory CLEMENT]

2010/8/11 Kevin Hilman <khilman@deeprootsystems.com>
>
> Gregory CLEMENT <gclement00@gmail.com> writes:
>
> > We notice that when system wake up from OFF mode, then CS is in
> > unactive state until the first SPI transfert.
> > For our design it lead to some conflict on this I/O.
> > Unactive state for CS when there is no transfert shoudl be the correct
> > behaviour: this is the purpose of these patches.
>
> This approach handles an off-mode transition during suspend, but if
> off-mode is enabled, you can also have an off-mode transition during
> idle.
>

Well maybe I didn't use the correct words.
During the system life, I monitored the CS behaviour using a oscilloscope.
I also activate debug in omap2_mcspi, so I see when driver disable the
clocks and restore context when device is not used.
Each time the CS is in the correct state. It is only when there is a
suspend with the following configuration that on resume the CS is in
wrong state( ie activated)


echo 1 > /mnt/pm_debug/enable_off_mode
echo 0 > /mnt/pm_debug/core_pwrdm/suspend
echo 1 > /mnt/pm_debug/voltage_off_while_idle


>
> Since you didn't describe what the conflicts you're seeing are, I would
> assume that you'll have the same problems in idle as in suspend, and
> this series doesn't address the idle case.

I didn't see any problem in idle case, just when system resume from a
suspend to ram (echo mem > /sys/power/state)

>
> Kevin
>
>
>
> > Gregory CLEMENT (2):
> >   spi: Add hook on suspend/resume for spi master
> >   spi/omap2_mcspi: When SPI wake up from OFF mode, CS is in wrong
> >     state: force it to unactive state
> >
> >  drivers/spi/omap2_mcspi.c |   11 ++++++++++-
> >  drivers/spi/spi.c         |   15 ++++++++++++++-
> >  include/linux/spi/spi.h   |    4 +++-
> >  3 files changed, 27 insertions(+), 3 deletions(-)
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html

--
Gregory CLEMENT
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 0/2] Put OMAP2 SPI CS in unactive state when return from suspend

[Kevin Hilman]

Gregory CLEMENT <gclement00@gmail.com> writes:

> 2010/8/11 Kevin Hilman <khilman@deeprootsystems.com>
>>
>> Gregory CLEMENT <gclement00@gmail.com> writes:
>>
>> > We notice that when system wake up from OFF mode, then CS is in
>> > unactive state until the first SPI transfert.
>> > For our design it lead to some conflict on this I/O.
>> > Unactive state for CS when there is no transfert shoudl be the correct
>> > behaviour: this is the purpose of these patches.
>>
>> This approach handles an off-mode transition during suspend, but if
>> off-mode is enabled, you can also have an off-mode transition during
>> idle.
>>
>
> Well maybe I didn't use the correct words.
> During the system life, I monitored the CS behaviour using a oscilloscope.
> I also activate debug in omap2_mcspi, so I see when driver disable the
> clocks and restore context when device is not used.
> Each time the CS is in the correct state. It is only when there is a
> suspend with the following configuration that on resume the CS is in
> wrong state( ie activated)

OK, that should be more clear in the changelog.  The way I understood
your description, the problem was related to an off-mode transition.

>
> echo 1 > /mnt/pm_debug/enable_off_mode
> echo 0 > /mnt/pm_debug/core_pwrdm/suspend

fyi... this part isn't needed.  You're telling the OMAP PM core that
you want the CORE powerdomain to go into off-mode, but you've you've
already done that by the 'enable_off_mode' flag, which enables *all*
powerdomains to hit off mode.

> echo 1 > /mnt/pm_debug/voltage_off_while_idle
>
>
>>
>> Since you didn't describe what the conflicts you're seeing are, I would
>> assume that you'll have the same problems in idle as in suspend, and
>> this series doesn't address the idle case.
>
> I didn't see any problem in idle case, just when system resume from a
> suspend to ram (echo mem > /sys/power/state)

OK, I'd recommend you update the changelog to make that more clear.

Then, I'll leave it to the SPI folks to review your patch.

Kevin