Skip to contentSkip to conversation

spi: omap2-mcspi: Add calls for pinctrl state select

PATCH Superseded [email protected] 2 participants 6 messages May 13, 2015 – Sep 14, 2015 5 messages not in the archive SPI

v1 of 2 Superseded Latest is v2 →

lore
Share & tools
lore

[email protected]

author
#0 lore raw

PATCH 1/1 spi: omap2-mcspi: Add calls for pinctrl state select

From: Pascal Huerst <[email protected]>

This adds calls to pinctrl subsystem in order to switch pin states on suspend/resume if you provide a "sleep" state in DT.

If no "sleep" state is provided in DT, these calls turn to NOPs, so we don't need error checking here.

Signed-off-by Pascal Huerst <[email protected]>
---
 drivers/spi/spi-omap2-mcspi.c | 14 ++++++++++++++
 1 file changed, 14 insertions(+)
drivers/spi/spi-omap2-mcspi.c +14 -0
index 4df8942..424f8cd 100644
@@ -24,6 +24,7 @@
 #include <linux/dma-mapping.h>
 #include <linux/dmaengine.h>
 #include <linux/omap-dma.h>
+#include <linux/pinctrl/consumer.h>
 #include <linux/platform_device.h>
 #include <linux/err.h>
 #include <linux/clk.h>

@@ -1502,14 +1503,27 @@ static int omap2_mcspi_resume(struct device *dev)
 	}
 	pm_runtime_mark_last_busy(mcspi->dev);
 	pm_runtime_put_autosuspend(mcspi->dev);
+
+	pinctrl_pm_select_default_state(dev);
+
+	return 0;
+}
+
+static int omap2_mcspi_suspend(struct device *dev)
+{
+	pinctrl_pm_select_sleep_state(dev);
+
 	return 0;
 }
+
 #else
+#define omap2_mcspi_suspend	NULL
 #define	omap2_mcspi_resume	NULL
 #endif
 
 static const struct dev_pm_ops omap2_mcspi_pm_ops = {
 	.resume = omap2_mcspi_resume,
+	.suspend = omap2_mcspi_suspend,
 	.runtime_resume	= omap_mcspi_runtime_resume,
 };

--
2.1.0

--
To unsubscribe from this list: send the line "unsubscribe linux-spi" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html

A message that is not in the archive (sent off-list or not yet received): 1431519316-30989-1-git-send-email-pascal.huerst-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org

#2 lore raw
Quoted 5 lines · On Wed, May 13, 2015 at 02:15:16PM +0200…

This adds calls to pinctrl subsystem in order to switch pin states on suspend/resume if you provide a "sleep" state in DT.

If no "sleep" state is provided in DT, these calls turn to NOPs, so we don't need error checking here.

We should still be checking if we succesfully changed the state when there is a state provided shouldn't we?

A message that is not in the archive (sent off-list or not yet received): [email protected]

author
#4 lore raw
Quoted 10 lines · Mark Brown
Quoted 5 lines · On Wed, May 13, 2015 at 02:15:16PM +0200…

This adds calls to pinctrl subsystem in order to switch pin states on suspend/resume if you provide a "sleep" state in DT.

If no "sleep" state is provided in DT, these calls turn to NOPs, so we don't need error checking here.

We should still be checking if we succesfully changed the state when there is a state provided shouldn't we?

I agree, but if I git grep for such calls, nobody seems to check the return values of these functions. Shall I add a check and print a message if the call fails?
--
To unsubscribe from this list: send the line "unsubscribe linux-spi" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html

A message that is not in the archive (sent off-list or not yet received): [email protected]

#6 lore raw
Quoted 8 lines · Pascal Huerst
Quoted 2 lines · Mark Brown

We should still be checking if we succesfully changed the state when there is a state provided shouldn't we?

I agree, but if I git grep for such calls, nobody seems to check the return values of these functions. Shall I add a check and print a message if the call fails?

Yes, please.

A message that is not in the archive (sent off-list or not yet received): [email protected]

author
#8 lore raw

Hey Mark,

Quoted 11 lines · Mark Brown
Quoted 8 lines · Pascal Huerst
Quoted 2 lines · Mark Brown

We should still be checking if we succesfully changed the state when there is a state provided shouldn't we?

I agree, but if I git grep for such calls, nobody seems to check the return values of these functions. Shall I add a check and print a message if the call fails?

Yes, please.

Sorry for the late reply.

There is already a message printed on failure in the subsystem. See:
http://lxr.free-electrons.com/source/drivers/pinctrl/core.c#L1250

So I don't see the need for another message, right?
--
To unsubscribe from this list: send the line "unsubscribe linux-spi" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html

A message that is not in the archive (sent off-list or not yet received): [email protected]

#10 lore raw
Quoted 11 lines · Pascal Huerst
Quoted 9 lines · Mark Brown
Quoted 8 lines · Pascal Huerst
Quoted 2 lines · Mark Brown

We should still be checking if we succesfully changed the state when there is a state provided shouldn't we?

I agree, but if I git grep for such calls, nobody seems to check the return values of these functions. Shall I add a check and print a message if the call fails?

Quoted 8 lines
Quoted 1 line

Yes, please.

Sorry for the late reply.

There is already a message printed on failure in the subsystem. See:
http://lxr.free-electrons.com/source/drivers/pinctrl/core.c#L1250

So I don't see the need for another message, right?

I was expecting to see us pass back an error code more than just printing an error message.