Put the OMAP2 SPI CS in inactive state when returning from suspend
v4 cover Put the OMAP2 SPI CS in inactive state when returning from suspend
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(-)
Quoted 11 lines · 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.
Quoted 6 lines
Gregory CLEMENT (1):
OMAP2: Spi: Force CS to be in inactive state after off-mode transitiondrivers/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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html