[PATCH v4 0/1] Put the OMAP2 SPI CS in inactive state when returning from suspend

[PATCH v4 0/1] Put the OMAP2 SPI CS in inactive state when returning from suspend

[Gregory CLEMENT]

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

* Change from v3:
Patch clean-up according to Kevin Hilman and checkpatch.
Now force CS to be in inactive state only if it was inactive when it was 
suspended.

Gregory CLEMENT (1):
   OMAP2: Spi: Force CS to be in inactive state after off-mode
     transition

  drivers/spi/omap2_mcspi.c |   35 +++++++++++++++++++++++++++++++++++
  1 files changed, 35 insertions(+), 0 deletions(-)

Re: [PATCH v4 0/1] Put the OMAP2 SPI CS in inactive state when returning from suspend

[Grant Likely]

On Fri, Nov 12, 2010 at 4:44 PM, Gregory CLEMENT
<gregory.clement@free-electrons.com> wrote:
> We notice that when system wake up from OFF mode, then CS is in inactive
> state until the first SPI transfer.
> For our design it lead to some conflict on this I/O.
> Inactive state for CS when there is no transfer should be the correct
> behavior: this is the purpose of these patches.
>
> * Change from v3:
> Patch clean-up according to Kevin Hilman and checkpatch.
> Now force CS to be in inactive state only if it was inactive when it was
> suspended.
>
> Gregory CLEMENT (1):
>  OMAP2: Spi: Force CS to be in inactive state after off-mode
>    transition
>
>  drivers/spi/omap2_mcspi.c |   35 +++++++++++++++++++++++++++++++++++
>  1 files changed, 35 insertions(+), 0 deletions(-)

Hi Gregory,

If you've only got one patch then please put all the explanation text
into the patch description.  Using a cover letter like this is only
useful when describing the context for a series (more than 1) of
patches.  Also, revision history should always be in patch
description, regardless of whether or not there is a cover letter (at
least for the subsystems that I maintain.  Otherwise, it is too easy
for vital information to get separated from the patch.

Thanks,
g.
--
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