| Message ID | 1370452099-24026-2-git-send-email-mugunthanvnm@ti.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Wed, Jun 05, 2013 at 10:38:15PM +0530, Mugunthan V N wrote: > From: Hebbar Gururaja <gururaja.hebbar@ti.com> > > Amend cpsw controller to optionally take a pin control handle and set > the state of the pins to: > > - "default" on boot, resume > - "sleep" on suspend() Linus Walleij posted some patches which factor the state setting code out into generic functions earlier on today - it probably makes sense to pick those up rather than open coding
On 6/6/2013 12:53 AM, Mark Brown wrote: > On Wed, Jun 05, 2013 at 10:38:15PM +0530, Mugunthan V N wrote: >> From: Hebbar Gururaja <gururaja.hebbar@ti.com> >> >> Amend cpsw controller to optionally take a pin control handle and set >> the state of the pins to: >> >> - "default" on boot, resume >> - "sleep" on suspend() > Linus Walleij posted some patches which factor the state setting code > out into generic functions earlier on today - it probably makes sense to > pick those up rather than open coding But this can go in as Linus Walleij's patch is not accepted yet. Once that is accepted and present in net git repo I will submit a separate patch to use those APIs from pin ctrl core. Regards Mugunthan V N -- 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
On Thu, Jun 06, 2013 at 11:29:39AM +0530, Mugunthan V N wrote: > On 6/6/2013 12:53 AM, Mark Brown wrote: > >Linus Walleij posted some patches which factor the state setting code > >out into generic functions earlier on today - it probably makes sense to > >pick those up rather than open coding > But this can go in as Linus Walleij's patch is not accepted yet. > Once that is > accepted and present in net git repo I will submit a separate patch to use > those APIs from pin ctrl core. Linus' change has pretty much gone in already but in any case what would be sensible here would be to write this in turns of Linus' changes and then send the patch to him to add to his series so it can go in via the same route. One of the major reasons for the patch was that lots of people were querying the amount of noise caused by this sort of change.
On Thu, Jun 6, 2013 at 10:50 AM, Mark Brown <broonie@kernel.org> wrote: > On Thu, Jun 06, 2013 at 11:29:39AM +0530, Mugunthan V N wrote: >> On 6/6/2013 12:53 AM, Mark Brown wrote: > >> >Linus Walleij posted some patches which factor the state setting code >> >out into generic functions earlier on today - it probably makes sense to >> >pick those up rather than open coding > >> But this can go in as Linus Walleij's patch is not accepted yet. >> Once that is >> accepted and present in net git repo I will submit a separate patch to use >> those APIs from pin ctrl core. > > Linus' change has pretty much gone in already but in any case what would > be sensible here would be to write this in turns of Linus' changes and > then send the patch to him to add to his series so it can go in via the > same route. One of the major reasons for the patch was that lots of > people were querying the amount of noise caused by this sort of change. I agree. We should be able to settle on the new core API quite soon, then I can carry the patch to this driver if you obtain David's ACK. Yours, Linus Walleij -- 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
From: Linus Walleij <linus.walleij@linaro.org> Date: Fri, 7 Jun 2013 09:31:58 +0200 > On Thu, Jun 6, 2013 at 10:50 AM, Mark Brown <broonie@kernel.org> wrote: >> On Thu, Jun 06, 2013 at 11:29:39AM +0530, Mugunthan V N wrote: >>> On 6/6/2013 12:53 AM, Mark Brown wrote: >> >>> >Linus Walleij posted some patches which factor the state setting code >>> >out into generic functions earlier on today - it probably makes sense to >>> >pick those up rather than open coding >> >>> But this can go in as Linus Walleij's patch is not accepted yet. >>> Once that is >>> accepted and present in net git repo I will submit a separate patch to use >>> those APIs from pin ctrl core. >> >> Linus' change has pretty much gone in already but in any case what would >> be sensible here would be to write this in turns of Linus' changes and >> then send the patch to him to add to his series so it can go in via the >> same route. One of the major reasons for the patch was that lots of >> people were querying the amount of noise caused by this sort of change. > > I agree. We should be able to settle on the new core API quite soon, > then I can carry the patch to this driver if you obtain David's ACK. If you want to merge the direct networking parts of this series into another tree, I'm fine with that: Acked-by: David S. Miller <davem@davemloft.net> -- 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
On 6/7/2013 1:12 PM, David Miller wrote: > From: Linus Walleij <linus.walleij@linaro.org> > Date: Fri, 7 Jun 2013 09:31:58 +0200 > >> On Thu, Jun 6, 2013 at 10:50 AM, Mark Brown <broonie@kernel.org> wrote: >>> On Thu, Jun 06, 2013 at 11:29:39AM +0530, Mugunthan V N wrote: >>>> On 6/6/2013 12:53 AM, Mark Brown wrote: >>>>> Linus Walleij posted some patches which factor the state setting code >>>>> out into generic functions earlier on today - it probably makes sense to >>>>> pick those up rather than open coding >>>> But this can go in as Linus Walleij's patch is not accepted yet. >>>> Once that is >>>> accepted and present in net git repo I will submit a separate patch to use >>>> those APIs from pin ctrl core. >>> Linus' change has pretty much gone in already but in any case what would >>> be sensible here would be to write this in turns of Linus' changes and >>> then send the patch to him to add to his series so it can go in via the >>> same route. One of the major reasons for the patch was that lots of >>> people were querying the amount of noise caused by this sort of change. >> I agree. We should be able to settle on the new core API quite soon, >> then I can carry the patch to this driver if you obtain David's ACK. > If you want to merge the direct networking parts of this series into > another tree, I'm fine with that: > > Acked-by: David S. Miller <davem@davemloft.net> David Can you the below patch series as i have adopted pinctrl PM api in another series, this patch has direct usage of pinctrl_select_state apis http://marc.info/?l=linux-netdev&m=137054250018667&w=2 Linus Walleij Please drop this patch series and take my other [atch set mentioned above with David's Ack. Regards Mugunthan V N -- 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
On Fri, Jun 7, 2013 at 4:49 PM, Mugunthan V N <mugunthanvnm@ti.com> wrote: >> If you want to merge the direct networking parts of this series into >> another tree, I'm fine with that: >> >> Acked-by: David S. Miller <davem@davemloft.net> > > David > > Can you the below patch series as i have adopted pinctrl PM api in another > series, > this patch has direct usage of pinctrl_select_state apis > http://marc.info/?l=linux-netdev&m=137054250018667&w=2 > > Linus Walleij > > Please drop this patch series and take my other [atch set mentioned above > with David's Ack. Sure I didn't see David ACK the new versions explicitly but since they're even less intrusive I'll apply them assuming his ACK on these versions too... Yours, Linus Walleij -- 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
From: Linus Walleij <linus.walleij@linaro.org> Date: Mon, 10 Jun 2013 17:48:16 +0200 > On Fri, Jun 7, 2013 at 4:49 PM, Mugunthan V N <mugunthanvnm@ti.com> wrote: > >>> If you want to merge the direct networking parts of this series into >>> another tree, I'm fine with that: >>> >>> Acked-by: David S. Miller <davem@davemloft.net> >> >> David >> >> Can you the below patch series as i have adopted pinctrl PM api in another >> series, >> this patch has direct usage of pinctrl_select_state apis >> http://marc.info/?l=linux-netdev&m=137054250018667&w=2 >> >> Linus Walleij >> >> Please drop this patch series and take my other [atch set mentioned above >> with David's Ack. > > Sure I didn't see David ACK the new versions explicitly but > since they're even less intrusive I'll apply them assuming > his ACK on these versions too... Just in case it isn't clear: Acked-by: David S. Miller <davem@davemloft.net> -- 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
diff --git a/drivers/net/ethernet/ti/cpsw.c b/drivers/net/ethernet/ti/cpsw.c index a45f64e..0599515 100644 --- a/drivers/net/ethernet/ti/cpsw.c +++ b/drivers/net/ethernet/ti/cpsw.c @@ -35,6 +35,7 @@ #include <linux/if_vlan.h> #include <linux/platform_data/cpsw.h> +#include <linux/pinctrl/consumer.h> #include "cpsw_ale.h" #include "cpts.h" @@ -351,6 +352,11 @@ struct cpsw_priv { bool irq_enabled; struct cpts *cpts; u32 emac_port; + + /* Two optional pin states - default & sleep */ + struct pinctrl *pinctrl; + struct pinctrl_state *pins_def; + struct pinctrl_state *pins_sleep; }; #define napi_to_priv(napi) container_of(napi, struct cpsw_priv, napi) @@ -1691,6 +1697,35 @@ static int cpsw_probe(struct platform_device *pdev) */ pm_runtime_enable(&pdev->dev); + priv->pinctrl = devm_pinctrl_get(&pdev->dev); + if (!IS_ERR(priv->pinctrl)) { + priv->pins_def = pinctrl_lookup_state(priv->pinctrl, + PINCTRL_STATE_DEFAULT); + /* enable pins to be muxed in and configured */ + if (IS_ERR(priv->pins_def)) + dev_warn(&pdev->dev, "could not get default pinstate\n"); + else + if (pinctrl_select_state(priv->pinctrl, + priv->pins_def)) + dev_err(&pdev->dev, + "could not set default pins\n"); + + priv->pins_sleep = pinctrl_lookup_state(priv->pinctrl, + PINCTRL_STATE_SLEEP); + if (IS_ERR(priv->pins_sleep)) + dev_warn(&pdev->dev, "could not get sleep pinstate\n"); + } else { + /* Since we continue even when pinctrl node is not found, + * Invalidate pins as not available. This is to make sure that + * IS_ERR(pins_xxx) results in failure when used. + */ + priv->pins_def = ERR_PTR(-ENODATA); + priv->pins_sleep = ERR_PTR(-ENODATA); + + dev_warn(&pdev->dev, + "pins are not configured from the driver\n"); + } + if (cpsw_probe_dt(&priv->data, pdev)) { pr_err("cpsw: platform data missing\n"); ret = -ENODEV; @@ -1974,11 +2009,17 @@ static int cpsw_suspend(struct device *dev) { struct platform_device *pdev = to_platform_device(dev); struct net_device *ndev = platform_get_drvdata(pdev); + struct cpsw_priv *priv = netdev_priv(ndev); if (netif_running(ndev)) cpsw_ndo_stop(ndev); pm_runtime_put_sync(&pdev->dev); + /* Optionally let pins go into sleep states */ + if (!IS_ERR(priv->pins_sleep)) + if (pinctrl_select_state(priv->pinctrl, priv->pins_sleep)) + dev_err(dev, "could not set pins to sleep state\n"); + return 0; } @@ -1986,8 +2027,15 @@ static int cpsw_resume(struct device *dev) { struct platform_device *pdev = to_platform_device(dev); struct net_device *ndev = platform_get_drvdata(pdev); + struct cpsw_priv *priv = netdev_priv(ndev); pm_runtime_get_sync(&pdev->dev); + + /* Optionaly enable pins to be muxed in and configured */ + if (!IS_ERR(priv->pins_def)) + if (pinctrl_select_state(priv->pinctrl, priv->pins_def)) + dev_err(dev, "could not set default pins\n"); + if (netif_running(ndev)) cpsw_ndo_open(ndev); return 0;