* [PATCH 1/6] ARM: dts: Fix pinctrl mask for omap3
2013-10-03 5:42 [PATCH 0/6] add support for omap wake-up interrupts via pinctrl-single, take2 Tony Lindgren
@ 2013-10-03 5:42 ` Tony Lindgren
2013-10-03 5:42 ` [PATCH 2/6] ARM: OMAP2+: Add support for auxdata Tony Lindgren
` (5 subsequent siblings)
6 siblings, 0 replies; 46+ messages in thread
From: Tony Lindgren @ 2013-10-03 5:42 UTC (permalink / raw)
To: linux-arm-kernel
The wake-up interrupt bit is available on omap3/4/5 processors
unlike what we claim. Without fixing it we cannot use it on
omap3 and the system configured for wake-up events will just
hang on wake-up.
Cc: Grygorii Strashko <grygorii.strashko@ti.com>
Cc: Beno?t Cousson <bcousson@baylibre.com>
Cc: devicetree at vger.kernel.org
Signed-off-by: Tony Lindgren <tony@atomide.com>
---
arch/arm/boot/dts/omap3.dtsi | 4 ++--
arch/arm/mach-omap2/mux.h | 4 +---
include/dt-bindings/pinctrl/omap.h | 4 +---
3 files changed, 4 insertions(+), 8 deletions(-)
diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index 7d95cda..b41bd57 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -108,7 +108,7 @@
#address-cells = <1>;
#size-cells = <0>;
pinctrl-single,register-width = <16>;
- pinctrl-single,function-mask = <0x7f1f>;
+ pinctrl-single,function-mask = <0xff1f>;
};
omap3_pmx_wkup: pinmux at 0x48002a00 {
@@ -117,7 +117,7 @@
#address-cells = <1>;
#size-cells = <0>;
pinctrl-single,register-width = <16>;
- pinctrl-single,function-mask = <0x7f1f>;
+ pinctrl-single,function-mask = <0xff1f>;
};
gpio1: gpio at 48310000 {
diff --git a/arch/arm/mach-omap2/mux.h b/arch/arm/mach-omap2/mux.h
index 5d2080e..16f78a9 100644
--- a/arch/arm/mach-omap2/mux.h
+++ b/arch/arm/mach-omap2/mux.h
@@ -28,7 +28,7 @@
#define OMAP_PULL_UP (1 << 4)
#define OMAP_ALTELECTRICALSEL (1 << 5)
-/* 34xx specific mux bit defines */
+/* omap3/4/5 specific mux bit defines */
#define OMAP_INPUT_EN (1 << 8)
#define OMAP_OFF_EN (1 << 9)
#define OMAP_OFFOUT_EN (1 << 10)
@@ -36,8 +36,6 @@
#define OMAP_OFF_PULL_EN (1 << 12)
#define OMAP_OFF_PULL_UP (1 << 13)
#define OMAP_WAKEUP_EN (1 << 14)
-
-/* 44xx specific mux bit defines */
#define OMAP_WAKEUP_EVENT (1 << 15)
/* Active pin states */
diff --git a/include/dt-bindings/pinctrl/omap.h b/include/dt-bindings/pinctrl/omap.h
index edbd250..bed35e3 100644
--- a/include/dt-bindings/pinctrl/omap.h
+++ b/include/dt-bindings/pinctrl/omap.h
@@ -23,7 +23,7 @@
#define PULL_UP (1 << 4)
#define ALTELECTRICALSEL (1 << 5)
-/* 34xx specific mux bit defines */
+/* omap3/4/5 specific mux bit defines */
#define INPUT_EN (1 << 8)
#define OFF_EN (1 << 9)
#define OFFOUT_EN (1 << 10)
@@ -31,8 +31,6 @@
#define OFF_PULL_EN (1 << 12)
#define OFF_PULL_UP (1 << 13)
#define WAKEUP_EN (1 << 14)
-
-/* 44xx specific mux bit defines */
#define WAKEUP_EVENT (1 << 15)
/* Active pin states */
^ permalink raw reply related [flat|nested] 46+ messages in thread* [PATCH 2/6] ARM: OMAP2+: Add support for auxdata
2013-10-03 5:42 [PATCH 0/6] add support for omap wake-up interrupts via pinctrl-single, take2 Tony Lindgren
2013-10-03 5:42 ` [PATCH 1/6] ARM: dts: Fix pinctrl mask for omap3 Tony Lindgren
@ 2013-10-03 5:42 ` Tony Lindgren
2013-10-03 5:42 ` [PATCH 3/6] pinctrl: single: Prepare for supporting SoC specific features Tony Lindgren
` (4 subsequent siblings)
6 siblings, 0 replies; 46+ messages in thread
From: Tony Lindgren @ 2013-10-03 5:42 UTC (permalink / raw)
To: linux-arm-kernel
For few things we're still going to be needing platform
data for device tree based drivers. Let's set up auxdata
handling and do it in pdata-quirks.c so we have all the
legacy calls in one place.
Signed-off-by: Tony Lindgren <tony@atomide.com>
---
arch/arm/mach-omap2/board-generic.c | 5 +----
arch/arm/mach-omap2/common.h | 3 ++-
arch/arm/mach-omap2/pdata-quirks.c | 11 ++++++++++-
3 files changed, 13 insertions(+), 6 deletions(-)
diff --git a/arch/arm/mach-omap2/board-generic.c b/arch/arm/mach-omap2/board-generic.c
index a66575f..3017a9d 100644
--- a/arch/arm/mach-omap2/board-generic.c
+++ b/arch/arm/mach-omap2/board-generic.c
@@ -35,10 +35,7 @@ static struct of_device_id omap_dt_match_table[] __initdata = {
static void __init omap_generic_init(void)
{
- omap_sdrc_init(NULL, NULL);
-
- of_platform_populate(NULL, omap_dt_match_table, NULL, NULL);
- pdata_quirks_init();
+ pdata_quirks_init(omap_dt_match_table);
}
#ifdef CONFIG_SOC_OMAP2420
diff --git a/arch/arm/mach-omap2/common.h b/arch/arm/mach-omap2/common.h
index fd059e0..c6aebf0 100644
--- a/arch/arm/mach-omap2/common.h
+++ b/arch/arm/mach-omap2/common.h
@@ -288,7 +288,8 @@ static inline void omap4_cpu_resume(void)
#endif
-void pdata_quirks_init(void);
+void pdata_quirks_init(struct of_device_id *);
+void omap_pcs_legacy_init(int irq, void (*rearm)(void));
struct omap_sdrc_params;
extern void omap_sdrc_init(struct omap_sdrc_params *sdrc_cs0,
diff --git a/arch/arm/mach-omap2/pdata-quirks.c b/arch/arm/mach-omap2/pdata-quirks.c
index 3d472db..c739631 100644
--- a/arch/arm/mach-omap2/pdata-quirks.c
+++ b/arch/arm/mach-omap2/pdata-quirks.c
@@ -11,6 +11,7 @@
#include <linux/gpio.h>
#include <linux/init.h>
#include <linux/kernel.h>
+#include <linux/of_platform.h>
#include <linux/wl12xx.h>
#include "common.h"
@@ -99,6 +100,10 @@ static void __init omap5_uevm_legacy_init(void)
}
#endif
+struct of_dev_auxdata omap_auxdata_lookup[] __initdata = {
+ { /* sentinel */ },
+};
+
static struct pdata_init pdata_quirks[] __initdata = {
#ifdef CONFIG_ARCH_OMAP3
{ "nokia,omap3-n9", hsmmc2_internal_input_clk, },
@@ -114,10 +119,14 @@ static struct pdata_init pdata_quirks[] __initdata = {
{ /* sentinel */ },
};
-void __init pdata_quirks_init(void)
+void __init pdata_quirks_init(struct of_device_id *omap_dt_match_table)
{
struct pdata_init *quirks = pdata_quirks;
+ omap_sdrc_init(NULL, NULL);
+ of_platform_populate(NULL, omap_dt_match_table,
+ omap_auxdata_lookup, NULL);
+
while (quirks->compatible) {
if (of_machine_is_compatible(quirks->compatible)) {
if (quirks->fn)
^ permalink raw reply related [flat|nested] 46+ messages in thread* [PATCH 3/6] pinctrl: single: Prepare for supporting SoC specific features
2013-10-03 5:42 [PATCH 0/6] add support for omap wake-up interrupts via pinctrl-single, take2 Tony Lindgren
2013-10-03 5:42 ` [PATCH 1/6] ARM: dts: Fix pinctrl mask for omap3 Tony Lindgren
2013-10-03 5:42 ` [PATCH 2/6] ARM: OMAP2+: Add support for auxdata Tony Lindgren
@ 2013-10-03 5:42 ` Tony Lindgren
2013-10-07 17:35 ` Tony Lindgren
2013-10-03 5:42 ` [PATCH 4/6] pinctrl: single: Add support for wake-up interrupts Tony Lindgren
` (3 subsequent siblings)
6 siblings, 1 reply; 46+ messages in thread
From: Tony Lindgren @ 2013-10-03 5:42 UTC (permalink / raw)
To: linux-arm-kernel
Let's replace is_pinconf with flags and add struct pcs_soc_data
so we can support SoC specific features like pin wake-up events.
Done in collaboration with Roger Quadros <rogerq@ti.com>.
Cc: Peter Ujfalusi <peter.ujfalusi@ti.com>
Cc: Grygorii Strashko <grygorii.strashko@ti.com>
Cc: Prakash Manjunathappa <prakash.pm@ti.com>
Cc: Haojian Zhuang <haojian.zhuang@linaro.org>
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: linux-kernel at vger.kernel.org
Signed-off-by: Roger Quadros <rogerq@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
---
drivers/pinctrl/pinctrl-single.c | 38 +++++++++++++++++++++++++++++---------
1 file changed, 29 insertions(+), 9 deletions(-)
diff --git a/drivers/pinctrl/pinctrl-single.c b/drivers/pinctrl/pinctrl-single.c
index a82ace4..f88d3d1 100644
--- a/drivers/pinctrl/pinctrl-single.c
+++ b/drivers/pinctrl/pinctrl-single.c
@@ -150,19 +150,27 @@ struct pcs_name {
};
/**
+ * struct pcs_soc_data - SoC specific settings
+ * @flags: initial SoC specific PCS_FEAT_xxx values
+ */
+struct pcs_soc_data {
+ unsigned flags;
+};
+
+/**
* struct pcs_device - pinctrl device instance
* @res: resources
* @base: virtual address of the controller
* @size: size of the ioremapped area
* @dev: device entry
* @pctl: pin controller device
+ * @flags: mask of PCS_FEAT_xxx values
* @mutex: mutex protecting the lists
* @width: bits per mux register
* @fmask: function register mask
* @fshift: function register shift
* @foff: value to turn mux off
* @fmax: max number of functions in fmask
- * @is_pinconf: whether supports pinconf
* @bits_per_pin:number of bits per pin
* @names: array of register names for pins
* @pins: physical pins on the SoC
@@ -183,6 +191,8 @@ struct pcs_device {
unsigned size;
struct device *dev;
struct pinctrl_dev *pctl;
+ unsigned flags;
+#define PCS_FEAT_PINCONF (1 << 0)
struct mutex mutex;
unsigned width;
unsigned fmask;
@@ -190,7 +200,6 @@ struct pcs_device {
unsigned foff;
unsigned fmax;
bool bits_per_mux;
- bool is_pinconf;
unsigned bits_per_pin;
struct pcs_name *names;
struct pcs_data pins;
@@ -206,6 +215,8 @@ struct pcs_device {
void (*write)(unsigned val, void __iomem *reg);
};
+#define PCS_HAS_PINCONF (pcs->flags & PCS_FEAT_PINCONF)
+
static int pcs_pinconf_get(struct pinctrl_dev *pctldev, unsigned pin,
unsigned long *config);
static int pcs_pinconf_set(struct pinctrl_dev *pctldev, unsigned pin,
@@ -1060,7 +1071,7 @@ static int pcs_parse_pinconf(struct pcs_device *pcs, struct device_node *np,
};
/* If pinconf isn't supported, don't parse properties in below. */
- if (!pcs->is_pinconf)
+ if (!PCS_HAS_PINCONF)
return 0;
/* cacluate how much properties are supported in current node */
@@ -1184,7 +1195,7 @@ static int pcs_parse_one_pinctrl_entry(struct pcs_device *pcs,
(*map)->data.mux.group = np->name;
(*map)->data.mux.function = np->name;
- if (pcs->is_pinconf) {
+ if (PCS_HAS_PINCONF) {
res = pcs_parse_pinconf(pcs, np, function, map);
if (res)
goto free_pingroups;
@@ -1305,7 +1316,7 @@ static int pcs_parse_bits_in_pinctrl_entry(struct pcs_device *pcs,
(*map)->data.mux.group = np->name;
(*map)->data.mux.function = np->name;
- if (pcs->is_pinconf) {
+ if (PCS_HAS_PINCONF) {
dev_err(pcs->dev, "pinconf not supported\n");
goto free_pingroups;
}
@@ -1525,6 +1536,7 @@ static int pcs_probe(struct platform_device *pdev)
const struct of_device_id *match;
struct resource *res;
struct pcs_device *pcs;
+ const struct pcs_soc_data *soc;
int ret;
match = of_match_device(pcs_of_match, &pdev->dev);
@@ -1541,7 +1553,8 @@ static int pcs_probe(struct platform_device *pdev)
INIT_LIST_HEAD(&pcs->pingroups);
INIT_LIST_HEAD(&pcs->functions);
INIT_LIST_HEAD(&pcs->gpiofuncs);
- pcs->is_pinconf = match->data;
+ soc = match->data;
+ pcs->flags = soc->flags;
PCS_GET_PROP_U32("pinctrl-single,register-width", &pcs->width,
"register width not specified\n");
@@ -1610,7 +1623,7 @@ static int pcs_probe(struct platform_device *pdev)
pcs->desc.name = DRIVER_NAME;
pcs->desc.pctlops = &pcs_pinctrl_ops;
pcs->desc.pmxops = &pcs_pinmux_ops;
- if (pcs->is_pinconf)
+ if (PCS_HAS_PINCONF)
pcs->desc.confops = &pcs_pinconf_ops;
pcs->desc.owner = THIS_MODULE;
@@ -1652,9 +1665,16 @@ static int pcs_remove(struct platform_device *pdev)
return 0;
}
+static const struct pcs_soc_data pinctrl_single = {
+};
+
+static const struct pcs_soc_data pinconf_single = {
+ .flags = PCS_FEAT_PINCONF,
+};
+
static struct of_device_id pcs_of_match[] = {
- { .compatible = "pinctrl-single", .data = (void *)false },
- { .compatible = "pinconf-single", .data = (void *)true },
+ { .compatible = "pinctrl-single", .data = &pinctrl_single },
+ { .compatible = "pinconf-single", .data = &pinconf_single },
{ },
};
MODULE_DEVICE_TABLE(of, pcs_of_match);
^ permalink raw reply related [flat|nested] 46+ messages in thread* [PATCH 3/6] pinctrl: single: Prepare for supporting SoC specific features
2013-10-03 5:42 ` [PATCH 3/6] pinctrl: single: Prepare for supporting SoC specific features Tony Lindgren
@ 2013-10-07 17:35 ` Tony Lindgren
2013-10-08 11:55 ` Linus Walleij
2013-10-09 13:43 ` Linus Walleij
0 siblings, 2 replies; 46+ messages in thread
From: Tony Lindgren @ 2013-10-07 17:35 UTC (permalink / raw)
To: linux-arm-kernel
Hi Linus W,
Any comments on the pinctrl patches 3 - 5 in this series?
These are badly needed to not break omap3 PM support when
we're moving to device tree based booting.
* Tony Lindgren <tony@atomide.com> [131002 22:50]:
> Let's replace is_pinconf with flags and add struct pcs_soc_data
> so we can support SoC specific features like pin wake-up events.
>
> Done in collaboration with Roger Quadros <rogerq@ti.com>.
>
> Cc: Peter Ujfalusi <peter.ujfalusi@ti.com>
> Cc: Grygorii Strashko <grygorii.strashko@ti.com>
> Cc: Prakash Manjunathappa <prakash.pm@ti.com>
> Cc: Haojian Zhuang <haojian.zhuang@linaro.org>
> Cc: Linus Walleij <linus.walleij@linaro.org>
> Cc: linux-kernel at vger.kernel.org
> Signed-off-by: Roger Quadros <rogerq@ti.com>
> Signed-off-by: Tony Lindgren <tony@atomide.com>
> ---
> drivers/pinctrl/pinctrl-single.c | 38 +++++++++++++++++++++++++++++---------
> 1 file changed, 29 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/pinctrl/pinctrl-single.c b/drivers/pinctrl/pinctrl-single.c
> index a82ace4..f88d3d1 100644
> --- a/drivers/pinctrl/pinctrl-single.c
> +++ b/drivers/pinctrl/pinctrl-single.c
> @@ -150,19 +150,27 @@ struct pcs_name {
> };
>
> /**
> + * struct pcs_soc_data - SoC specific settings
> + * @flags: initial SoC specific PCS_FEAT_xxx values
> + */
> +struct pcs_soc_data {
> + unsigned flags;
> +};
> +
> +/**
> * struct pcs_device - pinctrl device instance
> * @res: resources
> * @base: virtual address of the controller
> * @size: size of the ioremapped area
> * @dev: device entry
> * @pctl: pin controller device
> + * @flags: mask of PCS_FEAT_xxx values
> * @mutex: mutex protecting the lists
> * @width: bits per mux register
> * @fmask: function register mask
> * @fshift: function register shift
> * @foff: value to turn mux off
> * @fmax: max number of functions in fmask
> - * @is_pinconf: whether supports pinconf
> * @bits_per_pin:number of bits per pin
> * @names: array of register names for pins
> * @pins: physical pins on the SoC
> @@ -183,6 +191,8 @@ struct pcs_device {
> unsigned size;
> struct device *dev;
> struct pinctrl_dev *pctl;
> + unsigned flags;
> +#define PCS_FEAT_PINCONF (1 << 0)
> struct mutex mutex;
> unsigned width;
> unsigned fmask;
> @@ -190,7 +200,6 @@ struct pcs_device {
> unsigned foff;
> unsigned fmax;
> bool bits_per_mux;
> - bool is_pinconf;
> unsigned bits_per_pin;
> struct pcs_name *names;
> struct pcs_data pins;
> @@ -206,6 +215,8 @@ struct pcs_device {
> void (*write)(unsigned val, void __iomem *reg);
> };
>
> +#define PCS_HAS_PINCONF (pcs->flags & PCS_FEAT_PINCONF)
> +
> static int pcs_pinconf_get(struct pinctrl_dev *pctldev, unsigned pin,
> unsigned long *config);
> static int pcs_pinconf_set(struct pinctrl_dev *pctldev, unsigned pin,
> @@ -1060,7 +1071,7 @@ static int pcs_parse_pinconf(struct pcs_device *pcs, struct device_node *np,
> };
>
> /* If pinconf isn't supported, don't parse properties in below. */
> - if (!pcs->is_pinconf)
> + if (!PCS_HAS_PINCONF)
> return 0;
>
> /* cacluate how much properties are supported in current node */
> @@ -1184,7 +1195,7 @@ static int pcs_parse_one_pinctrl_entry(struct pcs_device *pcs,
> (*map)->data.mux.group = np->name;
> (*map)->data.mux.function = np->name;
>
> - if (pcs->is_pinconf) {
> + if (PCS_HAS_PINCONF) {
> res = pcs_parse_pinconf(pcs, np, function, map);
> if (res)
> goto free_pingroups;
> @@ -1305,7 +1316,7 @@ static int pcs_parse_bits_in_pinctrl_entry(struct pcs_device *pcs,
> (*map)->data.mux.group = np->name;
> (*map)->data.mux.function = np->name;
>
> - if (pcs->is_pinconf) {
> + if (PCS_HAS_PINCONF) {
> dev_err(pcs->dev, "pinconf not supported\n");
> goto free_pingroups;
> }
> @@ -1525,6 +1536,7 @@ static int pcs_probe(struct platform_device *pdev)
> const struct of_device_id *match;
> struct resource *res;
> struct pcs_device *pcs;
> + const struct pcs_soc_data *soc;
> int ret;
>
> match = of_match_device(pcs_of_match, &pdev->dev);
> @@ -1541,7 +1553,8 @@ static int pcs_probe(struct platform_device *pdev)
> INIT_LIST_HEAD(&pcs->pingroups);
> INIT_LIST_HEAD(&pcs->functions);
> INIT_LIST_HEAD(&pcs->gpiofuncs);
> - pcs->is_pinconf = match->data;
> + soc = match->data;
> + pcs->flags = soc->flags;
>
> PCS_GET_PROP_U32("pinctrl-single,register-width", &pcs->width,
> "register width not specified\n");
> @@ -1610,7 +1623,7 @@ static int pcs_probe(struct platform_device *pdev)
> pcs->desc.name = DRIVER_NAME;
> pcs->desc.pctlops = &pcs_pinctrl_ops;
> pcs->desc.pmxops = &pcs_pinmux_ops;
> - if (pcs->is_pinconf)
> + if (PCS_HAS_PINCONF)
> pcs->desc.confops = &pcs_pinconf_ops;
> pcs->desc.owner = THIS_MODULE;
>
> @@ -1652,9 +1665,16 @@ static int pcs_remove(struct platform_device *pdev)
> return 0;
> }
>
> +static const struct pcs_soc_data pinctrl_single = {
> +};
> +
> +static const struct pcs_soc_data pinconf_single = {
> + .flags = PCS_FEAT_PINCONF,
> +};
> +
> static struct of_device_id pcs_of_match[] = {
> - { .compatible = "pinctrl-single", .data = (void *)false },
> - { .compatible = "pinconf-single", .data = (void *)true },
> + { .compatible = "pinctrl-single", .data = &pinctrl_single },
> + { .compatible = "pinconf-single", .data = &pinconf_single },
> { },
> };
> MODULE_DEVICE_TABLE(of, pcs_of_match);
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [flat|nested] 46+ messages in thread* [PATCH 3/6] pinctrl: single: Prepare for supporting SoC specific features
2013-10-07 17:35 ` Tony Lindgren
@ 2013-10-08 11:55 ` Linus Walleij
2013-10-08 16:21 ` Tony Lindgren
2013-10-09 5:03 ` Haojian Zhuang
2013-10-09 13:43 ` Linus Walleij
1 sibling, 2 replies; 46+ messages in thread
From: Linus Walleij @ 2013-10-08 11:55 UTC (permalink / raw)
To: linux-arm-kernel
On Mon, Oct 7, 2013 at 7:35 PM, Tony Lindgren <tony@atomide.com> wrote:
> Hi Linus W,
>
> Any comments on the pinctrl patches 3 - 5 in this series?
I have no problems with this patch #3, as it is just changing syntax,
not semantics.
The problems start with patch #4.
I am tormented with mixed feelings about this, because from one point of
view I feel it is breaking the promise of pinctrl-single being a
driver for platforms
where a pin is controlled by a *single* register.
If this was pinctrl-foo.c I would not have been so much bothered,
but now it is something that was supposed to be self-contained and
simple, pertaining to a single register, starting to look like something
else.
This is a bit like: "oh yeah just one register controls the pins, but under
some circumstances I also want to mess with this register over here,
and then this register over there ..." etc.
I'd like Haojian to ACK this to proceed since he's also using this driver
now. Then I feel better on continuing down this road ...
Then I have a lesser comment on patch #4 since it makes it possible
for this pin controller to support wake-up interrupt, as I don't see how
this plays out with front-end GPIO controllers, but let's discuss that
in the context of that patch.
Yours,
Linus Walleij
^ permalink raw reply [flat|nested] 46+ messages in thread
* [PATCH 3/6] pinctrl: single: Prepare for supporting SoC specific features
2013-10-08 11:55 ` Linus Walleij
@ 2013-10-08 16:21 ` Tony Lindgren
2013-10-09 5:03 ` Haojian Zhuang
1 sibling, 0 replies; 46+ messages in thread
From: Tony Lindgren @ 2013-10-08 16:21 UTC (permalink / raw)
To: linux-arm-kernel
* Linus Walleij <linus.walleij@linaro.org> [131008 05:03]:
> On Mon, Oct 7, 2013 at 7:35 PM, Tony Lindgren <tony@atomide.com> wrote:
>
> > Hi Linus W,
> >
> > Any comments on the pinctrl patches 3 - 5 in this series?
>
> I have no problems with this patch #3, as it is just changing syntax,
> not semantics.
>
> The problems start with patch #4.
>
> I am tormented with mixed feelings about this, because from one point of
> view I feel it is breaking the promise of pinctrl-single being a
> driver for platforms
> where a pin is controlled by a *single* register.
It is still in that same *single* register. There are interrupt enable
and interrupt status bits for *every* pin register on most omaps.
> If this was pinctrl-foo.c I would not have been so much bothered,
> but now it is something that was supposed to be self-contained and
> simple, pertaining to a single register, starting to look like something
> else.
>
> This is a bit like: "oh yeah just one register controls the pins, but under
> some circumstances I also want to mess with this register over here,
> and then this register over there ..." etc.
Not true. If it was some other register I would have set it up as
a separate driver under drivers/irqchip.
> I'd like Haojian to ACK this to proceed since he's also using this driver
> now. Then I feel better on continuing down this road ...
>
> Then I have a lesser comment on patch #4 since it makes it possible
> for this pin controller to support wake-up interrupt, as I don't see how
> this plays out with front-end GPIO controllers, but let's discuss that
> in the context of that patch.
It's completely separate from the GPIO controller wake-up events.
Regards,
Tony
^ permalink raw reply [flat|nested] 46+ messages in thread
* [PATCH 3/6] pinctrl: single: Prepare for supporting SoC specific features
2013-10-08 11:55 ` Linus Walleij
2013-10-08 16:21 ` Tony Lindgren
@ 2013-10-09 5:03 ` Haojian Zhuang
1 sibling, 0 replies; 46+ messages in thread
From: Haojian Zhuang @ 2013-10-09 5:03 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, Oct 8, 2013 at 7:55 PM, Linus Walleij <linus.walleij@linaro.org> wrote:
> On Mon, Oct 7, 2013 at 7:35 PM, Tony Lindgren <tony@atomide.com> wrote:
>
>> Hi Linus W,
>>
>> Any comments on the pinctrl patches 3 - 5 in this series?
>
> I have no problems with this patch #3, as it is just changing syntax,
> not semantics.
>
> The problems start with patch #4.
>
> I am tormented with mixed feelings about this, because from one point of
> view I feel it is breaking the promise of pinctrl-single being a
> driver for platforms
> where a pin is controlled by a *single* register.
>
> If this was pinctrl-foo.c I would not have been so much bothered,
> but now it is something that was supposed to be self-contained and
> simple, pertaining to a single register, starting to look like something
> else.
>
> This is a bit like: "oh yeah just one register controls the pins, but under
> some circumstances I also want to mess with this register over here,
> and then this register over there ..." etc.
>
> I'd like Haojian to ACK this to proceed since he's also using this driver
> now. Then I feel better on continuing down this road ...
>
> Then I have a lesser comment on patch #4 since it makes it possible
> for this pin controller to support wake-up interrupt, as I don't see how
> this plays out with front-end GPIO controllers, but let's discuss that
> in the context of that patch.
>
> Yours,
> Linus Walleij
>
I'm OK on both #3 & #4. So Acked-by: Haojian Zhuang <haojian.zhuang@gmail.com>
Regards
Haojian
^ permalink raw reply [flat|nested] 46+ messages in thread
* [PATCH 3/6] pinctrl: single: Prepare for supporting SoC specific features
2013-10-07 17:35 ` Tony Lindgren
2013-10-08 11:55 ` Linus Walleij
@ 2013-10-09 13:43 ` Linus Walleij
2013-10-09 15:10 ` Tony Lindgren
1 sibling, 1 reply; 46+ messages in thread
From: Linus Walleij @ 2013-10-09 13:43 UTC (permalink / raw)
To: linux-arm-kernel
On Mon, Oct 7, 2013 at 7:35 PM, Tony Lindgren <tony@atomide.com> wrote:
> Hi Linus W,
>
> Any comments on the pinctrl patches 3 - 5 in this series?
Yes, after good explanations to my whimsical questions only this:
Acked-by: Linus Walleij <linus.walleij@linaro.org>
I guess you'll take these patches through ARM SoC?
Yours,
Linus Walleij
^ permalink raw reply [flat|nested] 46+ messages in thread
* [PATCH 3/6] pinctrl: single: Prepare for supporting SoC specific features
2013-10-09 13:43 ` Linus Walleij
@ 2013-10-09 15:10 ` Tony Lindgren
2013-10-10 15:35 ` Linus Walleij
0 siblings, 1 reply; 46+ messages in thread
From: Tony Lindgren @ 2013-10-09 15:10 UTC (permalink / raw)
To: linux-arm-kernel
* Linus Walleij <linus.walleij@linaro.org> [131009 06:51]:
> On Mon, Oct 7, 2013 at 7:35 PM, Tony Lindgren <tony@atomide.com> wrote:
>
> > Hi Linus W,
> >
> > Any comments on the pinctrl patches 3 - 5 in this series?
>
> Yes, after good explanations to my whimsical questions only this:
> Acked-by: Linus Walleij <linus.walleij@linaro.org>
OK thanks :)
> I guess you'll take these patches through ARM SoC?
I was thinking I'll set up an immutable branch for the three
pinctrl patches against -rc4 then both you and I can merge
them in as needed. Does that work for you?
I can also do a test merge with pinctrl/for-next also to make
sure there are no conflicts.
The rest of the patches should not be needed in the pinctrl
branch, but I need them all in one branch to keep things
working.
Regards,
Tony
^ permalink raw reply [flat|nested] 46+ messages in thread
* [PATCH 3/6] pinctrl: single: Prepare for supporting SoC specific features
2013-10-09 15:10 ` Tony Lindgren
@ 2013-10-10 15:35 ` Linus Walleij
2013-10-10 22:41 ` Tony Lindgren
0 siblings, 1 reply; 46+ messages in thread
From: Linus Walleij @ 2013-10-10 15:35 UTC (permalink / raw)
To: linux-arm-kernel
On Wed, Oct 9, 2013 at 5:10 PM, Tony Lindgren <tony@atomide.com> wrote:
> I was thinking I'll set up an immutable branch for the three
> pinctrl patches against -rc4 then both you and I can merge
> them in as needed. Does that work for you?
Hm it's fair enough to have them in your tree if they do
not collide ... especially if you want to do some of my
suggested follow-up moving the ioring handling down into
pinctrl-single on top of that.
> I can also do a test merge with pinctrl/for-next also to make
> sure there are no conflicts.
Sure, as long as that works you should be safe.
Yours,
Linus Walleij
^ permalink raw reply [flat|nested] 46+ messages in thread
* [PATCH 3/6] pinctrl: single: Prepare for supporting SoC specific features
2013-10-10 15:35 ` Linus Walleij
@ 2013-10-10 22:41 ` Tony Lindgren
0 siblings, 0 replies; 46+ messages in thread
From: Tony Lindgren @ 2013-10-10 22:41 UTC (permalink / raw)
To: linux-arm-kernel
* Linus Walleij <linus.walleij@linaro.org> [131010 08:43]:
> On Wed, Oct 9, 2013 at 5:10 PM, Tony Lindgren <tony@atomide.com> wrote:
>
> > I was thinking I'll set up an immutable branch for the three
> > pinctrl patches against -rc4 then both you and I can merge
> > them in as needed. Does that work for you?
>
> Hm it's fair enough to have them in your tree if they do
> not collide ... especially if you want to do some of my
> suggested follow-up moving the ioring handling down into
> pinctrl-single on top of that.
OK, the PRM changes will have to wait until omap3 is DT only,
probably not until v3.14.
> > I can also do a test merge with pinctrl/for-next also to make
> > sure there are no conflicts.
>
> Sure, as long as that works you should be safe.
Seems to merge with no conflicts and build just fine. Here's
the signed tag for the three pinctrl-single patches for you
to pull in too in case you are planning to make some pinctrl
wide changes. Let's consider those commits immutable now, if
I need to fix something I will post them as separate patches.
Regards,
Tony
The following changes since commit d0e639c9e06d44e713170031fe05fb60ebe680af:
Linux 3.12-rc4 (2013-10-06 14:00:20 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap tags/pinctrl-single-for-linus-for-v3.13-signed
for you to fetch changes up to dc7743aa3c49fabbc6dc9edbcf7df74d776ac32e:
pinctrl: single: Add support for auxdata (2013-10-10 15:30:47 -0700)
----------------------------------------------------------------
Changes to pinctrl-single to allow handling the wake-up
interrupts that most omaps have in each pinctrl register.
As I need these merged also into the omap tree, it was
agreed that I set them up into a separate branch for
both pinctrl tree and linux-omap tree to merge as needed.
----------------------------------------------------------------
Tony Lindgren (3):
pinctrl: single: Prepare for supporting SoC specific features
pinctrl: single: Add support for wake-up interrupts
pinctrl: single: Add support for auxdata
.../devicetree/bindings/pinctrl/pinctrl-single.txt | 11 +
drivers/pinctrl/pinctrl-single.c | 383 ++++++++++++++++++++-
include/linux/platform_data/pinctrl-single.h | 12 +
3 files changed, 397 insertions(+), 9 deletions(-)
create mode 100644 include/linux/platform_data/pinctrl-single.h
^ permalink raw reply [flat|nested] 46+ messages in thread
* [PATCH 4/6] pinctrl: single: Add support for wake-up interrupts
2013-10-03 5:42 [PATCH 0/6] add support for omap wake-up interrupts via pinctrl-single, take2 Tony Lindgren
` (2 preceding siblings ...)
2013-10-03 5:42 ` [PATCH 3/6] pinctrl: single: Prepare for supporting SoC specific features Tony Lindgren
@ 2013-10-03 5:42 ` Tony Lindgren
2013-10-03 17:50 ` Tony Lindgren
` (2 more replies)
2013-10-03 5:42 ` [PATCH 5/6] pinctrl: single: Add support for auxdata Tony Lindgren
` (2 subsequent siblings)
6 siblings, 3 replies; 46+ messages in thread
From: Tony Lindgren @ 2013-10-03 5:42 UTC (permalink / raw)
To: linux-arm-kernel
The pin control registers can have interrupts for example
for device wake-up. These interrupts can be treated as a
chained interrupt controller as suggested earlier by
Linus Walleij <linus.walleij@linaro.org>.
This patch adds support for interrupts in a way that
should be pretty generic, and works for the omaps that
support wake-up interrupts. On omaps, there's an
interrupt enable and interrupt status bit for each pin.
The two pinctrl domains on omaps share a single interrupt
from the PRM chained interrupt handler. Support for
other similar hardware should be easy to add.
Note that this patch does not attempt to handle the
wake-up interrupts automatically unlike the earlier
patches. This patch allows the device drivers to do
a request_irq() on the wake-up pins as needed. I'll
try to do also a separate generic patch for handling
the wake-up events automatically.
Also note that as this patch makes the pinctrl-single
an irq controller, the current bindings need some
extra trickery to use interrupts from two different
interrupt controllers for the same driver. So it
might be worth waiting a little on the patches
enabling the wake-up interrupts from drivers as there
should be a generic way to handle it coming. And also
there's been discussion of interrupts-extended binding
for using interrupts from multiple interrupt controllers.
In any case, this patch should be ready to go allowing
handling the wake-up interrupts in a generic way, or
separately from the device drivers.
Cc: Peter Ujfalusi <peter.ujfalusi@ti.com>
Cc: Grygorii Strashko <grygorii.strashko@ti.com>
Cc: Prakash Manjunathappa <prakash.pm@ti.com>
Cc: Roger Quadros <rogerq@ti.com>
Cc: Haojian Zhuang <haojian.zhuang@linaro.org>
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: linux-kernel at vger.kernel.org
Cc: Beno?t Cousson <bcousson@baylibre.com>
Cc: devicetree at vger.kernel.org
Signed-off-by: Tony Lindgren <tony@atomide.com>
---
.../devicetree/bindings/pinctrl/pinctrl-single.txt | 11 +
drivers/pinctrl/pinctrl-single.c | 325 ++++++++++++++++++++
2 files changed, 336 insertions(+)
diff --git a/Documentation/devicetree/bindings/pinctrl/pinctrl-single.txt b/Documentation/devicetree/bindings/pinctrl/pinctrl-single.txt
index 5a02e30..7069a0b 100644
--- a/Documentation/devicetree/bindings/pinctrl/pinctrl-single.txt
+++ b/Documentation/devicetree/bindings/pinctrl/pinctrl-single.txt
@@ -72,6 +72,13 @@ Optional properties:
/* pin base, nr pins & gpio function */
pinctrl-single,gpio-range = <&range 0 3 0 &range 3 9 1>;
+- interrupt-controller : standard interrupt controller binding if using
+ interrupts for wake-up events for example. In this case pinctrl-single
+ is set up as a chained interrupt controller and the wake-up interrupts
+ can be requested by the drivers using request_irq().
+
+- #interrupt-cells : standard interrupt binding if using interrupts
+
This driver assumes that there is only one register for each pin (unless the
pinctrl-single,bit-per-mux is set), and uses the common pinctrl bindings as
specified in the pinctrl-bindings.txt document in this directory.
@@ -121,6 +128,8 @@ pmx_core: pinmux at 4a100040 {
reg = <0x4a100040 0x0196>;
#address-cells = <1>;
#size-cells = <0>;
+ #interrupt-cells = <1>;
+ interrupt-controller;
pinctrl-single,register-width = <16>;
pinctrl-single,function-mask = <0xffff>;
};
@@ -131,6 +140,8 @@ pmx_wkup: pinmux at 4a31e040 {
reg = <0x4a31e040 0x0038>;
#address-cells = <1>;
#size-cells = <0>;
+ #interrupt-cells = <1>;
+ interrupt-controller;
pinctrl-single,register-width = <16>;
pinctrl-single,function-mask = <0xffff>;
};
diff --git a/drivers/pinctrl/pinctrl-single.c b/drivers/pinctrl/pinctrl-single.c
index f88d3d1..b4ff055 100644
--- a/drivers/pinctrl/pinctrl-single.c
+++ b/drivers/pinctrl/pinctrl-single.c
@@ -15,10 +15,14 @@
#include <linux/slab.h>
#include <linux/err.h>
#include <linux/list.h>
+#include <linux/interrupt.h>
+
+#include <linux/irqchip/chained_irq.h>
#include <linux/of.h>
#include <linux/of_device.h>
#include <linux/of_address.h>
+#include <linux/of_irq.h>
#include <linux/pinctrl/pinctrl.h>
#include <linux/pinctrl/pinmux.h>
@@ -152,9 +156,15 @@ struct pcs_name {
/**
* struct pcs_soc_data - SoC specific settings
* @flags: initial SoC specific PCS_FEAT_xxx values
+ * @irq: optional interrupt for the controller
+ * @irq_enable_mask: optional SoC specific interrupt enable mask
+ * @irq_status_mask: optional SoC specific interrupt status mask
*/
struct pcs_soc_data {
unsigned flags;
+ int irq;
+ unsigned irq_enable_mask;
+ unsigned irq_status_mask;
};
/**
@@ -165,6 +175,7 @@ struct pcs_soc_data {
* @dev: device entry
* @pctl: pin controller device
* @flags: mask of PCS_FEAT_xxx values
+ * @lock: spinlock for register access
* @mutex: mutex protecting the lists
* @width: bits per mux register
* @fmask: function register mask
@@ -179,6 +190,9 @@ struct pcs_soc_data {
* @pingroups: list of pingroups
* @functions: list of functions
* @gpiofuncs: list of gpio functions
+ * @irqs: list of interrupt registers
+ * @chip: chip container for this instance
+ * @domain: IRQ domain for this instance
* @ngroups: number of pingroups
* @nfuncs: number of functions
* @desc: pin controller descriptor
@@ -192,7 +206,11 @@ struct pcs_device {
struct device *dev;
struct pinctrl_dev *pctl;
unsigned flags;
+#define PCS_QUIRK_SHARED_IRQ (1 << 2)
+#define PCS_FEAT_IRQ (1 << 1)
#define PCS_FEAT_PINCONF (1 << 0)
+ struct pcs_soc_data socdata;
+ raw_spinlock_t lock;
struct mutex mutex;
unsigned width;
unsigned fmask;
@@ -208,6 +226,9 @@ struct pcs_device {
struct list_head pingroups;
struct list_head functions;
struct list_head gpiofuncs;
+ struct list_head irqs;
+ struct irq_chip chip;
+ struct irq_domain *domain;
unsigned ngroups;
unsigned nfuncs;
struct pinctrl_desc desc;
@@ -215,6 +236,8 @@ struct pcs_device {
void (*write)(unsigned val, void __iomem *reg);
};
+#define PCS_QUIRK_HAS_SHARED_IRQ (pcs->flags & PCS_QUIRK_SHARED_IRQ)
+#define PCS_HAS_IRQ (pcs->flags & PCS_FEAT_IRQ)
#define PCS_HAS_PINCONF (pcs->flags & PCS_FEAT_PINCONF)
static int pcs_pinconf_get(struct pinctrl_dev *pctldev, unsigned pin,
@@ -440,9 +463,11 @@ static int pcs_enable(struct pinctrl_dev *pctldev, unsigned fselector,
for (i = 0; i < func->nvals; i++) {
struct pcs_func_vals *vals;
+ unsigned long flags;
unsigned val, mask;
vals = &func->vals[i];
+ raw_spin_lock_irqsave(&pcs->lock, flags);
val = pcs->read(vals->reg);
if (pcs->bits_per_mux)
@@ -453,6 +478,7 @@ static int pcs_enable(struct pinctrl_dev *pctldev, unsigned fselector,
val &= ~mask;
val |= (vals->val & mask);
pcs->write(val, vals->reg);
+ raw_spin_unlock_irqrestore(&pcs->lock, flags);
}
return 0;
@@ -494,13 +520,16 @@ static void pcs_disable(struct pinctrl_dev *pctldev, unsigned fselector,
for (i = 0; i < func->nvals; i++) {
struct pcs_func_vals *vals;
+ unsigned long flags;
unsigned val;
vals = &func->vals[i];
+ raw_spin_lock_irqsave(&pcs->lock, flags);
val = pcs->read(vals->reg);
val &= ~pcs->fmask;
val |= pcs->foff << pcs->fshift;
pcs->write(val, vals->reg);
+ raw_spin_unlock_irqrestore(&pcs->lock, flags);
}
}
@@ -1451,11 +1480,33 @@ static void pcs_free_pingroups(struct pcs_device *pcs)
}
/**
+ * pcs_irq_free() - free interrupt
+ * @pcs: pcs driver instance
+ */
+static void pcs_irq_free(struct pcs_device *pcs)
+{
+ struct pcs_soc_data *pcs_soc = &pcs->socdata;
+
+ if (pcs_soc->irq < 0)
+ return;
+
+ if (pcs->domain)
+ irq_domain_remove(pcs->domain);
+
+ if (PCS_QUIRK_HAS_SHARED_IRQ)
+ free_irq(pcs_soc->irq, pcs_soc);
+ else
+ irq_set_chained_handler(pcs_soc->irq, NULL);
+}
+
+/**
* pcs_free_resources() - free memory used by this driver
* @pcs: pcs driver instance
*/
static void pcs_free_resources(struct pcs_device *pcs)
{
+ pcs_irq_free(pcs);
+
if (pcs->pctl)
pinctrl_unregister(pcs->pctl);
@@ -1504,6 +1555,259 @@ static int pcs_add_gpio_func(struct device_node *node, struct pcs_device *pcs)
}
return ret;
}
+/**
+ * @reg: virtual address of interrupt register
+ * @hwirq: hardware irq number
+ * @irq: virtual irq number
+ * @node: list node
+ */
+struct pcs_interrupt {
+ void __iomem *reg;
+ irq_hw_number_t hwirq;
+ unsigned int irq;
+ struct list_head node;
+};
+
+/**
+ * pcs_irq_set() - enables or disables an interrupt
+ *
+ * Note that this currently assumes one interrupt per pinctrl
+ * register that is typically used for wake-up events.
+ */
+static inline void pcs_irq_set(struct pcs_soc_data *pcs_soc,
+ int irq, const bool enable)
+{
+ struct pcs_device *pcs;
+ struct list_head *pos;
+ unsigned mask;
+
+ pcs = container_of(pcs_soc, struct pcs_device, socdata);
+ list_for_each(pos, &pcs->irqs) {
+ struct pcs_interrupt *pcswi;
+ unsigned soc_mask;
+
+ pcswi = list_entry(pos, struct pcs_interrupt, node);
+ if (irq != pcswi->hwirq)
+ continue;
+
+ soc_mask = pcs_soc->irq_enable_mask;
+ raw_spin_lock(&pcs->lock);
+ mask = pcs->read(pcswi->reg);
+ if (enable)
+ mask &= ~soc_mask;
+ else
+ mask |= soc_mask;
+ pcs->write(mask, pcswi->reg);
+ raw_spin_unlock(&pcs->lock);
+ }
+}
+
+/**
+ * pcs_irq_mask() - mask pinctrl interrupt
+ * @d: interrupt data
+ */
+static void pcs_irq_mask(struct irq_data *d)
+{
+ struct pcs_soc_data *pcs_soc = irq_data_get_irq_chip_data(d);
+
+ pcs_irq_set(pcs_soc, d->irq, false);
+}
+
+/**
+ * pcs_irq_unmask() - unmask pinctrl interrupt
+ * @d: interrupt data
+ */
+static void pcs_irq_unmask(struct irq_data *d)
+{
+ struct pcs_soc_data *pcs_soc = irq_data_get_irq_chip_data(d);
+
+ pcs_irq_set(pcs_soc, d->irq, true);
+}
+
+/**
+ * pcs_irq_set_wake() - toggle the suspend and resume wake up
+ * @d: interrupt data
+ * @state: wake-up state
+ *
+ * Note that this should be called only for suspend and resume.
+ * For runtime PM, the wake-up events should be enabled by default.
+ */
+static int pcs_irq_set_wake(struct irq_data *d, unsigned int state)
+{
+ if (state)
+ pcs_irq_unmask(d);
+ else
+ pcs_irq_mask(d);
+
+ return 0;
+}
+
+/**
+ * pcs_irq_handle() - common interrupt handler
+ * @pcs_irq: interrupt data
+ *
+ * Note that this currently assumes we have one interrupt bit per
+ * mux register. This interrupt is typically used for wake-up events.
+ * For more complex interrupts different handlers can be specified.
+ */
+static int pcs_irq_handle(struct pcs_soc_data *pcs_soc)
+{
+ struct pcs_device *pcs;
+ struct list_head *pos;
+ int count = 0;
+
+ pcs = container_of(pcs_soc, struct pcs_device, socdata);
+ list_for_each(pos, &pcs->irqs) {
+ struct pcs_interrupt *pcswi;
+ unsigned mask;
+
+ pcswi = list_entry(pos, struct pcs_interrupt, node);
+ raw_spin_lock(&pcs->lock);
+ mask = pcs->read(pcswi->reg);
+ raw_spin_unlock(&pcs->lock);
+ if (mask & pcs_soc->irq_status_mask) {
+ generic_handle_irq(irq_find_mapping(pcs->domain,
+ pcswi->hwirq));
+ count++;
+ }
+ }
+
+ return count;
+}
+
+/**
+ * pcs_irq_handler() - handler for the shared interrupt case
+ * @irq: interrupt
+ * @d: data
+ *
+ * Use this for cases where multiple instances of
+ * pinctrl-single share a single interrupt like on omaps.
+ */
+static irqreturn_t pcs_irq_handler(int irq, void *d)
+{
+ struct pcs_soc_data *pcs_soc = d;
+
+ return pcs_irq_handle(pcs_soc) ? IRQ_HANDLED : IRQ_NONE;
+}
+
+/**
+ * pcs_irq_handle() - handler for the dedicated chained interrupt case
+ * @irq: interrupt
+ * @desc: interrupt descriptor
+ *
+ * Use this if you have a separate interrupt for each
+ * pinctrl-single instance.
+ */
+static void pcs_irq_chain_handler(unsigned int irq, struct irq_desc *desc)
+{
+ struct pcs_soc_data *pcs_soc = irq_desc_get_handler_data(desc);
+ struct irq_chip *chip;
+ int res;
+
+ chip = irq_get_chip(irq);
+ chained_irq_enter(chip, desc);
+ res = pcs_irq_handle(pcs_soc);
+ if (!res)
+ handle_bad_irq(irq, desc);
+ chained_irq_exit(chip, desc);
+
+ return;
+}
+
+static int pcs_irqdomain_map(struct irq_domain *d, unsigned int irq,
+ irq_hw_number_t hwirq)
+{
+ struct pcs_soc_data *pcs_soc = d->host_data;
+ struct pcs_device *pcs;
+ struct pcs_interrupt *pcswi;
+
+ pcs = container_of(pcs_soc, struct pcs_device, socdata);
+ pcswi = devm_kzalloc(pcs->dev, sizeof(*pcswi), GFP_KERNEL);
+ if (!pcswi)
+ return -ENOMEM;
+
+ pcswi->reg = pcs->base + hwirq;
+ pcswi->hwirq = hwirq;
+ pcswi->irq = irq;
+
+ mutex_lock(&pcs->mutex);
+ list_add_tail(&pcswi->node, &pcs->irqs);
+ mutex_unlock(&pcs->mutex);
+
+ irq_set_chip_data(irq, pcs_soc);
+ irq_set_chip_and_handler(irq, &pcs->chip,
+ handle_level_irq);
+ set_irq_flags(irq, IRQF_VALID | IRQF_PROBE);
+
+ return 0;
+}
+
+static struct irq_domain_ops pcs_irqdomain_ops = {
+ .map = pcs_irqdomain_map,
+ .xlate = irq_domain_xlate_onecell,
+};
+
+/**
+ * pcs_irq_init_chained_handler() - set up a chained interrupt handler
+ * @pcs: pcs driver instance
+ * @np: device node pointer
+ */
+static int pcs_irq_init_chained_handler(struct pcs_device *pcs,
+ struct device_node *np)
+{
+ struct pcs_soc_data *pcs_soc = &pcs->socdata;
+ const char *name = "pinctrl";
+ int num_irqs;
+
+ if (!pcs_soc->irq_enable_mask ||
+ !pcs_soc->irq_status_mask) {
+ pcs_soc->irq = -1;
+ return -EINVAL;
+ }
+
+ INIT_LIST_HEAD(&pcs->irqs);
+ pcs->chip.name = name;
+ pcs->chip.irq_ack = pcs_irq_mask;
+ pcs->chip.irq_mask = pcs_irq_mask;
+ pcs->chip.irq_unmask = pcs_irq_unmask;
+ pcs->chip.irq_set_wake = pcs_irq_set_wake;
+
+ if (PCS_QUIRK_HAS_SHARED_IRQ) {
+ int res;
+
+ res = request_irq(pcs_soc->irq, pcs_irq_handler,
+ IRQF_SHARED | IRQF_NO_SUSPEND,
+ name, pcs_soc);
+ if (res) {
+ pcs_soc->irq = -1;
+ return res;
+ }
+ } else {
+ irq_set_handler_data(pcs_soc->irq, pcs_soc);
+ irq_set_chained_handler(pcs_soc->irq,
+ pcs_irq_chain_handler);
+ }
+
+ /* FIXME: Test rmmod */
+
+ /*
+ * We can use the register offset as the hardirq
+ * number as irq_domain_add_simple maps them lazily.
+ * This way we can easily support more than one
+ * interrupt per function if needed.
+ */
+ num_irqs = pcs->size;
+
+ pcs->domain = irq_domain_add_simple(np, num_irqs, 0,
+ &pcs_irqdomain_ops,
+ pcs_soc);
+ if (!pcs->domain) {
+ irq_set_chained_handler(pcs_soc->irq, NULL);
+ return -EINVAL;
+ }
+
+ return 0;
+}
#ifdef CONFIG_PM
static int pinctrl_single_suspend(struct platform_device *pdev,
@@ -1549,12 +1853,14 @@ static int pcs_probe(struct platform_device *pdev)
return -ENOMEM;
}
pcs->dev = &pdev->dev;
+ raw_spin_lock_init(&pcs->lock);
mutex_init(&pcs->mutex);
INIT_LIST_HEAD(&pcs->pingroups);
INIT_LIST_HEAD(&pcs->functions);
INIT_LIST_HEAD(&pcs->gpiofuncs);
soc = match->data;
pcs->flags = soc->flags;
+ memcpy(&pcs->socdata, soc, sizeof(*soc));
PCS_GET_PROP_U32("pinctrl-single,register-width", &pcs->width,
"register width not specified\n");
@@ -1642,6 +1948,16 @@ static int pcs_probe(struct platform_device *pdev)
if (ret < 0)
goto free;
+ pcs->socdata.irq = irq_of_parse_and_map(np, 0);
+ if (pcs->socdata.irq)
+ pcs->flags |= PCS_FEAT_IRQ;
+
+ if (PCS_HAS_IRQ) {
+ ret = pcs_irq_init_chained_handler(pcs, np);
+ if (ret < 0)
+ dev_warn(pcs->dev, "initialized with no interrupts\n");
+ }
+
dev_info(pcs->dev, "%i pins at pa %p size %u\n",
pcs->desc.npins, pcs->base, pcs->size);
@@ -1665,6 +1981,12 @@ static int pcs_remove(struct platform_device *pdev)
return 0;
}
+static const struct pcs_soc_data pinctrl_single_omap_wkup = {
+ .flags = PCS_QUIRK_SHARED_IRQ,
+ .irq_enable_mask = (1 << 14), /* OMAP_WAKEUP_EN */
+ .irq_status_mask = (1 << 15), /* OMAP_WAKEUP_EVENT */
+};
+
static const struct pcs_soc_data pinctrl_single = {
};
@@ -1673,6 +1995,9 @@ static const struct pcs_soc_data pinconf_single = {
};
static struct of_device_id pcs_of_match[] = {
+ { .compatible = "ti,omap3-padconf", .data = &pinctrl_single_omap_wkup },
+ { .compatible = "ti,omap4-padconf", .data = &pinctrl_single_omap_wkup },
+ { .compatible = "ti,omap5-padconf", .data = &pinctrl_single_omap_wkup },
{ .compatible = "pinctrl-single", .data = &pinctrl_single },
{ .compatible = "pinconf-single", .data = &pinconf_single },
{ },
^ permalink raw reply related [flat|nested] 46+ messages in thread* [PATCH 4/6] pinctrl: single: Add support for wake-up interrupts
2013-10-03 5:42 ` [PATCH 4/6] pinctrl: single: Add support for wake-up interrupts Tony Lindgren
@ 2013-10-03 17:50 ` Tony Lindgren
2013-10-08 12:10 ` Linus Walleij
2013-10-10 13:24 ` Roger Quadros
2 siblings, 0 replies; 46+ messages in thread
From: Tony Lindgren @ 2013-10-03 17:50 UTC (permalink / raw)
To: linux-arm-kernel
* Tony Lindgren <tony@atomide.com> [131002 22:51]:
> --- a/drivers/pinctrl/pinctrl-single.c
> +++ b/drivers/pinctrl/pinctrl-single.c
> +/**
> + * pcs_irq_set() - enables or disables an interrupt
> + *
> + * Note that this currently assumes one interrupt per pinctrl
> + * register that is typically used for wake-up events.
> + */
> +static inline void pcs_irq_set(struct pcs_soc_data *pcs_soc,
> + int irq, const bool enable)
> +{
> + struct pcs_device *pcs;
> + struct list_head *pos;
> + unsigned mask;
> +
> + pcs = container_of(pcs_soc, struct pcs_device, socdata);
> + list_for_each(pos, &pcs->irqs) {
> + struct pcs_interrupt *pcswi;
> + unsigned soc_mask;
> +
> + pcswi = list_entry(pos, struct pcs_interrupt, node);
> + if (irq != pcswi->hwirq)
> + continue;
Oops, this should be pcswi->irq instead, otherwise this will
never match. And it just happened to work for me as I had
the wake-up flags set from the bootloader..
> + soc_mask = pcs_soc->irq_enable_mask;
> + raw_spin_lock(&pcs->lock);
> + mask = pcs->read(pcswi->reg);
> + if (enable)
> + mask &= ~soc_mask;
> + else
> + mask |= soc_mask;
> + pcs->write(mask, pcswi->reg);
> + raw_spin_unlock(&pcs->lock);
> + }
> +}
And then the if (enable) mask needs to be swapped around for
this to work when the wake up events are not set by the
bootloader :)
> +static void pcs_irq_chain_handler(unsigned int irq, struct irq_desc *desc)
> +{
> + struct pcs_soc_data *pcs_soc = irq_desc_get_handler_data(desc);
> + struct irq_chip *chip;
> + int res;
> +
> + chip = irq_get_chip(irq);
> + chained_irq_enter(chip, desc);
> + res = pcs_irq_handle(pcs_soc);
> + if (!res)
> + handle_bad_irq(irq, desc);
> + chained_irq_exit(chip, desc);
> +
> + return;
> +}
Looks like handle_bad_irq is not exported for modules, so I've
just made it into a comment for now.
> + /* FIXME: Test rmmod */
And this can be removed now, I've briefly tested it as a
loadable module by not claiming any pins.
Updated patch below,
Tony
8<---------------------
From: Tony Lindgren <tony@atomide.com>
Date: Wed, 2 Oct 2013 21:39:40 -0700
Subject: [PATCH] pinctrl: single: Add support for wake-up interrupts
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
The pin control registers can have interrupts for example
for device wake-up. These interrupts can be treated as a
chained interrupt controller as suggested earlier by
Linus Walleij <linus.walleij@linaro.org>.
This patch adds support for interrupts in a way that
should be pretty generic, and works for the omaps that
support wake-up interrupts. On omaps, there's an
interrupt enable and interrupt status bit for each pin.
The two pinctrl domains on omaps share a single interrupt
from the PRM chained interrupt handler. Support for
other similar hardware should be easy to add.
Note that this patch does not attempt to handle the
wake-up interrupts automatically unlike the earlier
patches. This patch allows the device drivers to do
a request_irq() on the wake-up pins as needed. I'll
try to do also a separate generic patch for handling
the wake-up events automatically.
Also note that as this patch makes the pinctrl-single
an irq controller, the current bindings need some
extra trickery to use interrupts from two different
interrupt controllers for the same driver. So it
might be worth waiting a little on the patches
enabling the wake-up interrupts from drivers as there
should be a generic way to handle it coming. And also
there's been discussion of interrupts-extended binding
for using interrupts from multiple interrupt controllers.
In any case, this patch should be ready to go allowing
handling the wake-up interrupts in a generic way, or
separately from the device drivers.
Cc: Peter Ujfalusi <peter.ujfalusi@ti.com>
Cc: Grygorii Strashko <grygorii.strashko@ti.com>
Cc: Prakash Manjunathappa <prakash.pm@ti.com>
Cc: Roger Quadros <rogerq@ti.com>
Cc: Haojian Zhuang <haojian.zhuang@linaro.org>
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: linux-kernel at vger.kernel.org
Cc: Beno?t Cousson <bcousson@baylibre.com>
Cc: devicetree at vger.kernel.org
Signed-off-by: Tony Lindgren <tony@atomide.com>
diff --git a/Documentation/devicetree/bindings/pinctrl/pinctrl-single.txt b/Documentation/devicetree/bindings/pinctrl/pinctrl-single.txt
index 5a02e30..7069a0b 100644
--- a/Documentation/devicetree/bindings/pinctrl/pinctrl-single.txt
+++ b/Documentation/devicetree/bindings/pinctrl/pinctrl-single.txt
@@ -72,6 +72,13 @@ Optional properties:
/* pin base, nr pins & gpio function */
pinctrl-single,gpio-range = <&range 0 3 0 &range 3 9 1>;
+- interrupt-controller : standard interrupt controller binding if using
+ interrupts for wake-up events for example. In this case pinctrl-single
+ is set up as a chained interrupt controller and the wake-up interrupts
+ can be requested by the drivers using request_irq().
+
+- #interrupt-cells : standard interrupt binding if using interrupts
+
This driver assumes that there is only one register for each pin (unless the
pinctrl-single,bit-per-mux is set), and uses the common pinctrl bindings as
specified in the pinctrl-bindings.txt document in this directory.
@@ -121,6 +128,8 @@ pmx_core: pinmux at 4a100040 {
reg = <0x4a100040 0x0196>;
#address-cells = <1>;
#size-cells = <0>;
+ #interrupt-cells = <1>;
+ interrupt-controller;
pinctrl-single,register-width = <16>;
pinctrl-single,function-mask = <0xffff>;
};
@@ -131,6 +140,8 @@ pmx_wkup: pinmux at 4a31e040 {
reg = <0x4a31e040 0x0038>;
#address-cells = <1>;
#size-cells = <0>;
+ #interrupt-cells = <1>;
+ interrupt-controller;
pinctrl-single,register-width = <16>;
pinctrl-single,function-mask = <0xffff>;
};
diff --git a/drivers/pinctrl/pinctrl-single.c b/drivers/pinctrl/pinctrl-single.c
index f88d3d1..dad65df 100644
--- a/drivers/pinctrl/pinctrl-single.c
+++ b/drivers/pinctrl/pinctrl-single.c
@@ -15,10 +15,14 @@
#include <linux/slab.h>
#include <linux/err.h>
#include <linux/list.h>
+#include <linux/interrupt.h>
+
+#include <linux/irqchip/chained_irq.h>
#include <linux/of.h>
#include <linux/of_device.h>
#include <linux/of_address.h>
+#include <linux/of_irq.h>
#include <linux/pinctrl/pinctrl.h>
#include <linux/pinctrl/pinmux.h>
@@ -152,9 +156,15 @@ struct pcs_name {
/**
* struct pcs_soc_data - SoC specific settings
* @flags: initial SoC specific PCS_FEAT_xxx values
+ * @irq: optional interrupt for the controller
+ * @irq_enable_mask: optional SoC specific interrupt enable mask
+ * @irq_status_mask: optional SoC specific interrupt status mask
*/
struct pcs_soc_data {
unsigned flags;
+ int irq;
+ unsigned irq_enable_mask;
+ unsigned irq_status_mask;
};
/**
@@ -165,6 +175,7 @@ struct pcs_soc_data {
* @dev: device entry
* @pctl: pin controller device
* @flags: mask of PCS_FEAT_xxx values
+ * @lock: spinlock for register access
* @mutex: mutex protecting the lists
* @width: bits per mux register
* @fmask: function register mask
@@ -179,6 +190,9 @@ struct pcs_soc_data {
* @pingroups: list of pingroups
* @functions: list of functions
* @gpiofuncs: list of gpio functions
+ * @irqs: list of interrupt registers
+ * @chip: chip container for this instance
+ * @domain: IRQ domain for this instance
* @ngroups: number of pingroups
* @nfuncs: number of functions
* @desc: pin controller descriptor
@@ -192,7 +206,11 @@ struct pcs_device {
struct device *dev;
struct pinctrl_dev *pctl;
unsigned flags;
+#define PCS_QUIRK_SHARED_IRQ (1 << 2)
+#define PCS_FEAT_IRQ (1 << 1)
#define PCS_FEAT_PINCONF (1 << 0)
+ struct pcs_soc_data socdata;
+ raw_spinlock_t lock;
struct mutex mutex;
unsigned width;
unsigned fmask;
@@ -208,6 +226,9 @@ struct pcs_device {
struct list_head pingroups;
struct list_head functions;
struct list_head gpiofuncs;
+ struct list_head irqs;
+ struct irq_chip chip;
+ struct irq_domain *domain;
unsigned ngroups;
unsigned nfuncs;
struct pinctrl_desc desc;
@@ -215,6 +236,8 @@ struct pcs_device {
void (*write)(unsigned val, void __iomem *reg);
};
+#define PCS_QUIRK_HAS_SHARED_IRQ (pcs->flags & PCS_QUIRK_SHARED_IRQ)
+#define PCS_HAS_IRQ (pcs->flags & PCS_FEAT_IRQ)
#define PCS_HAS_PINCONF (pcs->flags & PCS_FEAT_PINCONF)
static int pcs_pinconf_get(struct pinctrl_dev *pctldev, unsigned pin,
@@ -440,9 +463,11 @@ static int pcs_enable(struct pinctrl_dev *pctldev, unsigned fselector,
for (i = 0; i < func->nvals; i++) {
struct pcs_func_vals *vals;
+ unsigned long flags;
unsigned val, mask;
vals = &func->vals[i];
+ raw_spin_lock_irqsave(&pcs->lock, flags);
val = pcs->read(vals->reg);
if (pcs->bits_per_mux)
@@ -453,6 +478,7 @@ static int pcs_enable(struct pinctrl_dev *pctldev, unsigned fselector,
val &= ~mask;
val |= (vals->val & mask);
pcs->write(val, vals->reg);
+ raw_spin_unlock_irqrestore(&pcs->lock, flags);
}
return 0;
@@ -494,13 +520,16 @@ static void pcs_disable(struct pinctrl_dev *pctldev, unsigned fselector,
for (i = 0; i < func->nvals; i++) {
struct pcs_func_vals *vals;
+ unsigned long flags;
unsigned val;
vals = &func->vals[i];
+ raw_spin_lock_irqsave(&pcs->lock, flags);
val = pcs->read(vals->reg);
val &= ~pcs->fmask;
val |= pcs->foff << pcs->fshift;
pcs->write(val, vals->reg);
+ raw_spin_unlock_irqrestore(&pcs->lock, flags);
}
}
@@ -1451,11 +1480,33 @@ static void pcs_free_pingroups(struct pcs_device *pcs)
}
/**
+ * pcs_irq_free() - free interrupt
+ * @pcs: pcs driver instance
+ */
+static void pcs_irq_free(struct pcs_device *pcs)
+{
+ struct pcs_soc_data *pcs_soc = &pcs->socdata;
+
+ if (pcs_soc->irq < 0)
+ return;
+
+ if (pcs->domain)
+ irq_domain_remove(pcs->domain);
+
+ if (PCS_QUIRK_HAS_SHARED_IRQ)
+ free_irq(pcs_soc->irq, pcs_soc);
+ else
+ irq_set_chained_handler(pcs_soc->irq, NULL);
+}
+
+/**
* pcs_free_resources() - free memory used by this driver
* @pcs: pcs driver instance
*/
static void pcs_free_resources(struct pcs_device *pcs)
{
+ pcs_irq_free(pcs);
+
if (pcs->pctl)
pinctrl_unregister(pcs->pctl);
@@ -1504,6 +1555,256 @@ static int pcs_add_gpio_func(struct device_node *node, struct pcs_device *pcs)
}
return ret;
}
+/**
+ * @reg: virtual address of interrupt register
+ * @hwirq: hardware irq number
+ * @irq: virtual irq number
+ * @node: list node
+ */
+struct pcs_interrupt {
+ void __iomem *reg;
+ irq_hw_number_t hwirq;
+ unsigned int irq;
+ struct list_head node;
+};
+
+/**
+ * pcs_irq_set() - enables or disables an interrupt
+ *
+ * Note that this currently assumes one interrupt per pinctrl
+ * register that is typically used for wake-up events.
+ */
+static inline void pcs_irq_set(struct pcs_soc_data *pcs_soc,
+ int irq, const bool enable)
+{
+ struct pcs_device *pcs;
+ struct list_head *pos;
+ unsigned mask;
+
+ pcs = container_of(pcs_soc, struct pcs_device, socdata);
+ list_for_each(pos, &pcs->irqs) {
+ struct pcs_interrupt *pcswi;
+ unsigned soc_mask;
+
+ pcswi = list_entry(pos, struct pcs_interrupt, node);
+ if (irq != pcswi->irq)
+ continue;
+
+ soc_mask = pcs_soc->irq_enable_mask;
+ raw_spin_lock(&pcs->lock);
+ mask = pcs->read(pcswi->reg);
+ if (enable)
+ mask |= soc_mask;
+ else
+ mask &= ~soc_mask;
+ pcs->write(mask, pcswi->reg);
+ raw_spin_unlock(&pcs->lock);
+ }
+}
+
+/**
+ * pcs_irq_mask() - mask pinctrl interrupt
+ * @d: interrupt data
+ */
+static void pcs_irq_mask(struct irq_data *d)
+{
+ struct pcs_soc_data *pcs_soc = irq_data_get_irq_chip_data(d);
+
+ pcs_irq_set(pcs_soc, d->irq, false);
+}
+
+/**
+ * pcs_irq_unmask() - unmask pinctrl interrupt
+ * @d: interrupt data
+ */
+static void pcs_irq_unmask(struct irq_data *d)
+{
+ struct pcs_soc_data *pcs_soc = irq_data_get_irq_chip_data(d);
+
+ pcs_irq_set(pcs_soc, d->irq, true);
+}
+
+/**
+ * pcs_irq_set_wake() - toggle the suspend and resume wake up
+ * @d: interrupt data
+ * @state: wake-up state
+ *
+ * Note that this should be called only for suspend and resume.
+ * For runtime PM, the wake-up events should be enabled by default.
+ */
+static int pcs_irq_set_wake(struct irq_data *d, unsigned int state)
+{
+ if (state)
+ pcs_irq_unmask(d);
+ else
+ pcs_irq_mask(d);
+
+ return 0;
+}
+
+/**
+ * pcs_irq_handle() - common interrupt handler
+ * @pcs_irq: interrupt data
+ *
+ * Note that this currently assumes we have one interrupt bit per
+ * mux register. This interrupt is typically used for wake-up events.
+ * For more complex interrupts different handlers can be specified.
+ */
+static int pcs_irq_handle(struct pcs_soc_data *pcs_soc)
+{
+ struct pcs_device *pcs;
+ struct list_head *pos;
+ int count = 0;
+
+ pcs = container_of(pcs_soc, struct pcs_device, socdata);
+ list_for_each(pos, &pcs->irqs) {
+ struct pcs_interrupt *pcswi;
+ unsigned mask;
+
+ pcswi = list_entry(pos, struct pcs_interrupt, node);
+ raw_spin_lock(&pcs->lock);
+ mask = pcs->read(pcswi->reg);
+ raw_spin_unlock(&pcs->lock);
+ if (mask & pcs_soc->irq_status_mask) {
+ generic_handle_irq(irq_find_mapping(pcs->domain,
+ pcswi->hwirq));
+ count++;
+ }
+ }
+
+ return count;
+}
+
+/**
+ * pcs_irq_handler() - handler for the shared interrupt case
+ * @irq: interrupt
+ * @d: data
+ *
+ * Use this for cases where multiple instances of
+ * pinctrl-single share a single interrupt like on omaps.
+ */
+static irqreturn_t pcs_irq_handler(int irq, void *d)
+{
+ struct pcs_soc_data *pcs_soc = d;
+
+ return pcs_irq_handle(pcs_soc) ? IRQ_HANDLED : IRQ_NONE;
+}
+
+/**
+ * pcs_irq_handle() - handler for the dedicated chained interrupt case
+ * @irq: interrupt
+ * @desc: interrupt descriptor
+ *
+ * Use this if you have a separate interrupt for each
+ * pinctrl-single instance.
+ */
+static void pcs_irq_chain_handler(unsigned int irq, struct irq_desc *desc)
+{
+ struct pcs_soc_data *pcs_soc = irq_desc_get_handler_data(desc);
+ struct irq_chip *chip;
+ int res;
+
+ chip = irq_get_chip(irq);
+ chained_irq_enter(chip, desc);
+ res = pcs_irq_handle(pcs_soc);
+ /* REVISIT: export and add handle_bad_irq(irq, desc)? */
+ chained_irq_exit(chip, desc);
+
+ return;
+}
+
+static int pcs_irqdomain_map(struct irq_domain *d, unsigned int irq,
+ irq_hw_number_t hwirq)
+{
+ struct pcs_soc_data *pcs_soc = d->host_data;
+ struct pcs_device *pcs;
+ struct pcs_interrupt *pcswi;
+
+ pcs = container_of(pcs_soc, struct pcs_device, socdata);
+ pcswi = devm_kzalloc(pcs->dev, sizeof(*pcswi), GFP_KERNEL);
+ if (!pcswi)
+ return -ENOMEM;
+
+ pcswi->reg = pcs->base + hwirq;
+ pcswi->hwirq = hwirq;
+ pcswi->irq = irq;
+
+ mutex_lock(&pcs->mutex);
+ list_add_tail(&pcswi->node, &pcs->irqs);
+ mutex_unlock(&pcs->mutex);
+
+ irq_set_chip_data(irq, pcs_soc);
+ irq_set_chip_and_handler(irq, &pcs->chip,
+ handle_level_irq);
+ set_irq_flags(irq, IRQF_VALID | IRQF_PROBE);
+
+ return 0;
+}
+
+static struct irq_domain_ops pcs_irqdomain_ops = {
+ .map = pcs_irqdomain_map,
+ .xlate = irq_domain_xlate_onecell,
+};
+
+/**
+ * pcs_irq_init_chained_handler() - set up a chained interrupt handler
+ * @pcs: pcs driver instance
+ * @np: device node pointer
+ */
+static int pcs_irq_init_chained_handler(struct pcs_device *pcs,
+ struct device_node *np)
+{
+ struct pcs_soc_data *pcs_soc = &pcs->socdata;
+ const char *name = "pinctrl";
+ int num_irqs;
+
+ if (!pcs_soc->irq_enable_mask ||
+ !pcs_soc->irq_status_mask) {
+ pcs_soc->irq = -1;
+ return -EINVAL;
+ }
+
+ INIT_LIST_HEAD(&pcs->irqs);
+ pcs->chip.name = name;
+ pcs->chip.irq_ack = pcs_irq_mask;
+ pcs->chip.irq_mask = pcs_irq_mask;
+ pcs->chip.irq_unmask = pcs_irq_unmask;
+ pcs->chip.irq_set_wake = pcs_irq_set_wake;
+
+ if (PCS_QUIRK_HAS_SHARED_IRQ) {
+ int res;
+
+ res = request_irq(pcs_soc->irq, pcs_irq_handler,
+ IRQF_SHARED | IRQF_NO_SUSPEND,
+ name, pcs_soc);
+ if (res) {
+ pcs_soc->irq = -1;
+ return res;
+ }
+ } else {
+ irq_set_handler_data(pcs_soc->irq, pcs_soc);
+ irq_set_chained_handler(pcs_soc->irq,
+ pcs_irq_chain_handler);
+ }
+
+ /*
+ * We can use the register offset as the hardirq
+ * number as irq_domain_add_simple maps them lazily.
+ * This way we can easily support more than one
+ * interrupt per function if needed.
+ */
+ num_irqs = pcs->size;
+
+ pcs->domain = irq_domain_add_simple(np, num_irqs, 0,
+ &pcs_irqdomain_ops,
+ pcs_soc);
+ if (!pcs->domain) {
+ irq_set_chained_handler(pcs_soc->irq, NULL);
+ return -EINVAL;
+ }
+
+ return 0;
+}
#ifdef CONFIG_PM
static int pinctrl_single_suspend(struct platform_device *pdev,
@@ -1549,12 +1850,14 @@ static int pcs_probe(struct platform_device *pdev)
return -ENOMEM;
}
pcs->dev = &pdev->dev;
+ raw_spin_lock_init(&pcs->lock);
mutex_init(&pcs->mutex);
INIT_LIST_HEAD(&pcs->pingroups);
INIT_LIST_HEAD(&pcs->functions);
INIT_LIST_HEAD(&pcs->gpiofuncs);
soc = match->data;
pcs->flags = soc->flags;
+ memcpy(&pcs->socdata, soc, sizeof(*soc));
PCS_GET_PROP_U32("pinctrl-single,register-width", &pcs->width,
"register width not specified\n");
@@ -1642,6 +1945,16 @@ static int pcs_probe(struct platform_device *pdev)
if (ret < 0)
goto free;
+ pcs->socdata.irq = irq_of_parse_and_map(np, 0);
+ if (pcs->socdata.irq)
+ pcs->flags |= PCS_FEAT_IRQ;
+
+ if (PCS_HAS_IRQ) {
+ ret = pcs_irq_init_chained_handler(pcs, np);
+ if (ret < 0)
+ dev_warn(pcs->dev, "initialized with no interrupts\n");
+ }
+
dev_info(pcs->dev, "%i pins at pa %p size %u\n",
pcs->desc.npins, pcs->base, pcs->size);
@@ -1665,6 +1978,12 @@ static int pcs_remove(struct platform_device *pdev)
return 0;
}
+static const struct pcs_soc_data pinctrl_single_omap_wkup = {
+ .flags = PCS_QUIRK_SHARED_IRQ,
+ .irq_enable_mask = (1 << 14), /* OMAP_WAKEUP_EN */
+ .irq_status_mask = (1 << 15), /* OMAP_WAKEUP_EVENT */
+};
+
static const struct pcs_soc_data pinctrl_single = {
};
@@ -1673,6 +1992,9 @@ static const struct pcs_soc_data pinconf_single = {
};
static struct of_device_id pcs_of_match[] = {
+ { .compatible = "ti,omap3-padconf", .data = &pinctrl_single_omap_wkup },
+ { .compatible = "ti,omap4-padconf", .data = &pinctrl_single_omap_wkup },
+ { .compatible = "ti,omap5-padconf", .data = &pinctrl_single_omap_wkup },
{ .compatible = "pinctrl-single", .data = &pinctrl_single },
{ .compatible = "pinconf-single", .data = &pinconf_single },
{ },
^ permalink raw reply related [flat|nested] 46+ messages in thread* [PATCH 4/6] pinctrl: single: Add support for wake-up interrupts
2013-10-03 5:42 ` [PATCH 4/6] pinctrl: single: Add support for wake-up interrupts Tony Lindgren
2013-10-03 17:50 ` Tony Lindgren
@ 2013-10-08 12:10 ` Linus Walleij
2013-10-08 16:05 ` Tony Lindgren
2013-10-10 13:24 ` Roger Quadros
2 siblings, 1 reply; 46+ messages in thread
From: Linus Walleij @ 2013-10-08 12:10 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, Oct 3, 2013 at 7:42 AM, Tony Lindgren <tony@atomide.com> wrote:
> This patch adds support for interrupts in a way that
> should be pretty generic, and works for the omaps that
> support wake-up interrupts. On omaps, there's an
> interrupt enable and interrupt status bit for each pin.
So to be clear: is this enable and status bit in the *same*
register as all other settings? Then it warrants having this
under pinctrl-single still and I feel a bit better about this.
Second: how does this relate to the case where say
gpio-omap is using the same pins as a back-end (this
is a real usecase right)?
So gpio-omap already supports gpio_to_irq() and
it does not support enable_irq_wake() on the GPIO
lines as well.
How does this play together? Is it like the pins have a set
of wakeup IRQs and then the GPIO block has *another*
set of wakeup IRQs?
And if you do enable_irq_wake() on the GPIO line,
should this not fall through to the pinctrl driver, so we
should add pinctrl_gpio_enable_wake() and
pinctrl_gpio_disable_wake() just like we have
pinctrl_gpio_direction_input() and friends today,
so that this request falls through to the pinctrl driver
when a wakeup on a certain GPIO line is requested?
Now gpio-omap.c does not seem to use the pinctrl
back-end commands, instead of using e.g.
pinctrl_gpio_request() and GPIO to pin ranges it
seems to use this hack:
static void _enable_gpio_module(struct gpio_bank *bank, unsigned offset)
{
if (bank->regs->pinctrl) {
void __iomem *reg = bank->base + bank->regs->pinctrl;
/* Claim the pin for MPU */
__raw_writel(__raw_readl(reg) | (1 << offset), reg);
}
Can't we please make the OMAP GPIO driver use the
pinctrl back-end with gpio ranges properly *before* we proceed
to doing this kind of stuff? I think it is already looking
like a bit of layered hacks :-(
Haojian is already using the pinctrl-single as backend to
another GPIO controller (I think it's pinctrl-pl061.c) so surely
this should be possible to do right.
IIRC there are also other OMAP GPIO blocks so we need
to look@the large picture here, for all of them.
Yours,
Linus Walleij
^ permalink raw reply [flat|nested] 46+ messages in thread* [PATCH 4/6] pinctrl: single: Add support for wake-up interrupts
2013-10-08 12:10 ` Linus Walleij
@ 2013-10-08 16:05 ` Tony Lindgren
0 siblings, 0 replies; 46+ messages in thread
From: Tony Lindgren @ 2013-10-08 16:05 UTC (permalink / raw)
To: linux-arm-kernel
* Linus Walleij <linus.walleij@linaro.org> [131008 05:18]:
> On Thu, Oct 3, 2013 at 7:42 AM, Tony Lindgren <tony@atomide.com> wrote:
>
> > This patch adds support for interrupts in a way that
> > should be pretty generic, and works for the omaps that
> > support wake-up interrupts. On omaps, there's an
> > interrupt enable and interrupt status bit for each pin.
>
> So to be clear: is this enable and status bit in the *same*
> register as all other settings? Then it warrants having this
> under pinctrl-single still and I feel a bit better about this.
Yes there's a status bit on most omaps in the same register
for each pin.
There is a PRM interrupt that has wake-up events for internal
domain wake-ups and io chain wake-ups. The PRM interrupt is
already a chained IRQ. After we get the wake-up interrupt we
need to check the pinctrl registers that have wake-up bit
enabled for the wake-up status bit.
> Second: how does this relate to the case where say
> gpio-omap is using the same pins as a back-end (this
> is a real usecase right)?
The GPIO is a separate hardware block on omaps and has
it's own separate wake-up events.
> So gpio-omap already supports gpio_to_irq() and
> it does not support enable_irq_wake() on the GPIO
> lines as well.
Yeah those are specific to the GPIO block, and not related
to this driver. The GPIO lines have their own wake-up
mechanism that works for retention idle.
For off-idle, only for the first GPIO bank stays powered.
The other GPIO banks get powered down in off-idle mode.
> How does this play together? Is it like the pins have a set
> of wakeup IRQs and then the GPIO block has *another*
> set of wakeup IRQs?
Yes that's correct, they are completely separate.
> And if you do enable_irq_wake() on the GPIO line,
> should this not fall through to the pinctrl driver, so we
> should add pinctrl_gpio_enable_wake() and
> pinctrl_gpio_disable_wake() just like we have
> pinctrl_gpio_direction_input() and friends today,
> so that this request falls through to the pinctrl driver
> when a wakeup on a certain GPIO line is requested?
That's not needed for most cases at this point, the GPIO
block is already handling it's internal wake-up events.
Eventually we should also handle the corner case of
GPIO wake-up line connected to a GPIO bank that's not
the first bank for off-idle. For most low-power hardware
designs that's not needed as the critial pins typically
are placed in the first GPIO bank for this reason.
But let's first figure out how we want to handle the mapping
of wake-up interrupts to device interrupts in general.
Most omap devices have a dedicated io chain wake-up line, so
that's really the key thing to get working first.
> Now gpio-omap.c does not seem to use the pinctrl
> back-end commands, instead of using e.g.
> pinctrl_gpio_request() and GPIO to pin ranges it
> seems to use this hack:
>
> static void _enable_gpio_module(struct gpio_bank *bank, unsigned offset)
> {
> if (bank->regs->pinctrl) {
> void __iomem *reg = bank->base + bank->regs->pinctrl;
>
> /* Claim the pin for MPU */
> __raw_writel(__raw_readl(reg) | (1 << offset), reg);
> }
>
> Can't we please make the OMAP GPIO driver use the
> pinctrl back-end with gpio ranges properly *before* we proceed
> to doing this kind of stuff? I think it is already looking
> like a bit of layered hacks :-(
Heh, that's not true. And I can totally see where the confusion
comes from :)
The naming "pinctrl" in the GPIO driver is a bit confusing and
it's use predates the pinctrl framework and has been in the GPIO
driver for probably 10 years or so.
The above does not have anything to do with the pinctrl
framework or this pinctrl driver. That is to mux the GPIO pins
inside the GPIO block between the ARM core and the DSP.
> Haojian is already using the pinctrl-single as backend to
> another GPIO controller (I think it's pinctrl-pl061.c) so surely
> this should be possible to do right.
Sure we can make the GPIO off-idle wake-up handling automatic
for the GPIO not in the first bank, but that's really a separate
patch.
> IIRC there are also other OMAP GPIO blocks so we need
> to look at the large picture here, for all of them.
Sorry I don't know which other OMAP GPIO blocks you're talking
about, care to be a bit more specific?
All the omaps I've seen use the gpio-omap.c. The other GPIOs
are typically on I2C chips.
Regards,
Tony
^ permalink raw reply [flat|nested] 46+ messages in thread
* [PATCH 4/6] pinctrl: single: Add support for wake-up interrupts
2013-10-03 5:42 ` [PATCH 4/6] pinctrl: single: Add support for wake-up interrupts Tony Lindgren
2013-10-03 17:50 ` Tony Lindgren
2013-10-08 12:10 ` Linus Walleij
@ 2013-10-10 13:24 ` Roger Quadros
2013-10-10 14:04 ` Linus Walleij
2013-10-10 16:00 ` Tony Lindgren
2 siblings, 2 replies; 46+ messages in thread
From: Roger Quadros @ 2013-10-10 13:24 UTC (permalink / raw)
To: linux-arm-kernel
Hi Tony,
On 10/03/2013 08:42 AM, Tony Lindgren wrote:
> The pin control registers can have interrupts for example
> for device wake-up. These interrupts can be treated as a
> chained interrupt controller as suggested earlier by
> Linus Walleij <linus.walleij@linaro.org>.
>
> This patch adds support for interrupts in a way that
> should be pretty generic, and works for the omaps that
> support wake-up interrupts. On omaps, there's an
> interrupt enable and interrupt status bit for each pin.
> The two pinctrl domains on omaps share a single interrupt
> from the PRM chained interrupt handler. Support for
> other similar hardware should be easy to add.
>
> Note that this patch does not attempt to handle the
> wake-up interrupts automatically unlike the earlier
> patches. This patch allows the device drivers to do
> a request_irq() on the wake-up pins as needed. I'll
> try to do also a separate generic patch for handling
> the wake-up events automatically.
>
> Also note that as this patch makes the pinctrl-single
> an irq controller, the current bindings need some
> extra trickery to use interrupts from two different
> interrupt controllers for the same driver. So it
> might be worth waiting a little on the patches
> enabling the wake-up interrupts from drivers as there
> should be a generic way to handle it coming. And also
> there's been discussion of interrupts-extended binding
> for using interrupts from multiple interrupt controllers.
>
> In any case, this patch should be ready to go allowing
> handling the wake-up interrupts in a generic way, or
> separately from the device drivers.
>
> Cc: Peter Ujfalusi <peter.ujfalusi@ti.com>
> Cc: Grygorii Strashko <grygorii.strashko@ti.com>
> Cc: Prakash Manjunathappa <prakash.pm@ti.com>
> Cc: Roger Quadros <rogerq@ti.com>
> Cc: Haojian Zhuang <haojian.zhuang@linaro.org>
> Cc: Linus Walleij <linus.walleij@linaro.org>
> Cc: linux-kernel at vger.kernel.org
> Cc: Beno?t Cousson <bcousson@baylibre.com>
> Cc: devicetree at vger.kernel.org
> Signed-off-by: Tony Lindgren <tony@atomide.com>
> ---
> .../devicetree/bindings/pinctrl/pinctrl-single.txt | 11 +
> drivers/pinctrl/pinctrl-single.c | 325 ++++++++++++++++++++
> 2 files changed, 336 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/pinctrl/pinctrl-single.txt b/Documentation/devicetree/bindings/pinctrl/pinctrl-single.txt
> index 5a02e30..7069a0b 100644
> --- a/Documentation/devicetree/bindings/pinctrl/pinctrl-single.txt
> +++ b/Documentation/devicetree/bindings/pinctrl/pinctrl-single.txt
> @@ -72,6 +72,13 @@ Optional properties:
> /* pin base, nr pins & gpio function */
> pinctrl-single,gpio-range = <&range 0 3 0 &range 3 9 1>;
>
> +- interrupt-controller : standard interrupt controller binding if using
> + interrupts for wake-up events for example. In this case pinctrl-single
> + is set up as a chained interrupt controller and the wake-up interrupts
> + can be requested by the drivers using request_irq().
> +
> +- #interrupt-cells : standard interrupt binding if using interrupts
> +
> This driver assumes that there is only one register for each pin (unless the
> pinctrl-single,bit-per-mux is set), and uses the common pinctrl bindings as
> specified in the pinctrl-bindings.txt document in this directory.
> @@ -121,6 +128,8 @@ pmx_core: pinmux at 4a100040 {
> reg = <0x4a100040 0x0196>;
> #address-cells = <1>;
> #size-cells = <0>;
> + #interrupt-cells = <1>;
> + interrupt-controller;
> pinctrl-single,register-width = <16>;
> pinctrl-single,function-mask = <0xffff>;
> };
> @@ -131,6 +140,8 @@ pmx_wkup: pinmux at 4a31e040 {
> reg = <0x4a31e040 0x0038>;
> #address-cells = <1>;
> #size-cells = <0>;
> + #interrupt-cells = <1>;
> + interrupt-controller;
> pinctrl-single,register-width = <16>;
> pinctrl-single,function-mask = <0xffff>;
> };
> diff --git a/drivers/pinctrl/pinctrl-single.c b/drivers/pinctrl/pinctrl-single.c
> index f88d3d1..b4ff055 100644
> --- a/drivers/pinctrl/pinctrl-single.c
> +++ b/drivers/pinctrl/pinctrl-single.c
> @@ -15,10 +15,14 @@
> #include <linux/slab.h>
> #include <linux/err.h>
> #include <linux/list.h>
> +#include <linux/interrupt.h>
> +
> +#include <linux/irqchip/chained_irq.h>
>
> #include <linux/of.h>
> #include <linux/of_device.h>
> #include <linux/of_address.h>
> +#include <linux/of_irq.h>
>
> #include <linux/pinctrl/pinctrl.h>
> #include <linux/pinctrl/pinmux.h>
> @@ -152,9 +156,15 @@ struct pcs_name {
> /**
> * struct pcs_soc_data - SoC specific settings
> * @flags: initial SoC specific PCS_FEAT_xxx values
> + * @irq: optional interrupt for the controller
> + * @irq_enable_mask: optional SoC specific interrupt enable mask
> + * @irq_status_mask: optional SoC specific interrupt status mask
> */
> struct pcs_soc_data {
> unsigned flags;
> + int irq;
> + unsigned irq_enable_mask;
> + unsigned irq_status_mask;
> };
>
> /**
> @@ -165,6 +175,7 @@ struct pcs_soc_data {
> * @dev: device entry
> * @pctl: pin controller device
> * @flags: mask of PCS_FEAT_xxx values
> + * @lock: spinlock for register access
> * @mutex: mutex protecting the lists
> * @width: bits per mux register
> * @fmask: function register mask
> @@ -179,6 +190,9 @@ struct pcs_soc_data {
> * @pingroups: list of pingroups
> * @functions: list of functions
> * @gpiofuncs: list of gpio functions
> + * @irqs: list of interrupt registers
> + * @chip: chip container for this instance
> + * @domain: IRQ domain for this instance
> * @ngroups: number of pingroups
> * @nfuncs: number of functions
> * @desc: pin controller descriptor
> @@ -192,7 +206,11 @@ struct pcs_device {
> struct device *dev;
> struct pinctrl_dev *pctl;
> unsigned flags;
> +#define PCS_QUIRK_SHARED_IRQ (1 << 2)
> +#define PCS_FEAT_IRQ (1 << 1)
> #define PCS_FEAT_PINCONF (1 << 0)
> + struct pcs_soc_data socdata;
> + raw_spinlock_t lock;
> struct mutex mutex;
> unsigned width;
> unsigned fmask;
> @@ -208,6 +226,9 @@ struct pcs_device {
> struct list_head pingroups;
> struct list_head functions;
> struct list_head gpiofuncs;
> + struct list_head irqs;
> + struct irq_chip chip;
> + struct irq_domain *domain;
> unsigned ngroups;
> unsigned nfuncs;
> struct pinctrl_desc desc;
> @@ -215,6 +236,8 @@ struct pcs_device {
> void (*write)(unsigned val, void __iomem *reg);
> };
>
> +#define PCS_QUIRK_HAS_SHARED_IRQ (pcs->flags & PCS_QUIRK_SHARED_IRQ)
> +#define PCS_HAS_IRQ (pcs->flags & PCS_FEAT_IRQ)
> #define PCS_HAS_PINCONF (pcs->flags & PCS_FEAT_PINCONF)
>
> static int pcs_pinconf_get(struct pinctrl_dev *pctldev, unsigned pin,
> @@ -440,9 +463,11 @@ static int pcs_enable(struct pinctrl_dev *pctldev, unsigned fselector,
>
> for (i = 0; i < func->nvals; i++) {
> struct pcs_func_vals *vals;
> + unsigned long flags;
> unsigned val, mask;
>
> vals = &func->vals[i];
> + raw_spin_lock_irqsave(&pcs->lock, flags);
> val = pcs->read(vals->reg);
>
> if (pcs->bits_per_mux)
> @@ -453,6 +478,7 @@ static int pcs_enable(struct pinctrl_dev *pctldev, unsigned fselector,
> val &= ~mask;
> val |= (vals->val & mask);
> pcs->write(val, vals->reg);
> + raw_spin_unlock_irqrestore(&pcs->lock, flags);
> }
>
> return 0;
> @@ -494,13 +520,16 @@ static void pcs_disable(struct pinctrl_dev *pctldev, unsigned fselector,
>
> for (i = 0; i < func->nvals; i++) {
> struct pcs_func_vals *vals;
> + unsigned long flags;
> unsigned val;
>
> vals = &func->vals[i];
> + raw_spin_lock_irqsave(&pcs->lock, flags);
> val = pcs->read(vals->reg);
> val &= ~pcs->fmask;
> val |= pcs->foff << pcs->fshift;
> pcs->write(val, vals->reg);
> + raw_spin_unlock_irqrestore(&pcs->lock, flags);
> }
> }
>
> @@ -1451,11 +1480,33 @@ static void pcs_free_pingroups(struct pcs_device *pcs)
> }
>
> /**
> + * pcs_irq_free() - free interrupt
> + * @pcs: pcs driver instance
> + */
> +static void pcs_irq_free(struct pcs_device *pcs)
> +{
> + struct pcs_soc_data *pcs_soc = &pcs->socdata;
> +
> + if (pcs_soc->irq < 0)
> + return;
> +
> + if (pcs->domain)
> + irq_domain_remove(pcs->domain);
> +
> + if (PCS_QUIRK_HAS_SHARED_IRQ)
> + free_irq(pcs_soc->irq, pcs_soc);
> + else
> + irq_set_chained_handler(pcs_soc->irq, NULL);
> +}
> +
> +/**
> * pcs_free_resources() - free memory used by this driver
> * @pcs: pcs driver instance
> */
> static void pcs_free_resources(struct pcs_device *pcs)
> {
> + pcs_irq_free(pcs);
> +
> if (pcs->pctl)
> pinctrl_unregister(pcs->pctl);
>
> @@ -1504,6 +1555,259 @@ static int pcs_add_gpio_func(struct device_node *node, struct pcs_device *pcs)
> }
> return ret;
> }
> +/**
> + * @reg: virtual address of interrupt register
> + * @hwirq: hardware irq number
> + * @irq: virtual irq number
> + * @node: list node
> + */
> +struct pcs_interrupt {
> + void __iomem *reg;
> + irq_hw_number_t hwirq;
> + unsigned int irq;
> + struct list_head node;
> +};
> +
> +/**
> + * pcs_irq_set() - enables or disables an interrupt
> + *
> + * Note that this currently assumes one interrupt per pinctrl
> + * register that is typically used for wake-up events.
> + */
> +static inline void pcs_irq_set(struct pcs_soc_data *pcs_soc,
> + int irq, const bool enable)
> +{
> + struct pcs_device *pcs;
> + struct list_head *pos;
> + unsigned mask;
> +
> + pcs = container_of(pcs_soc, struct pcs_device, socdata);
> + list_for_each(pos, &pcs->irqs) {
> + struct pcs_interrupt *pcswi;
> + unsigned soc_mask;
> +
> + pcswi = list_entry(pos, struct pcs_interrupt, node);
> + if (irq != pcswi->hwirq)
> + continue;
> +
> + soc_mask = pcs_soc->irq_enable_mask;
> + raw_spin_lock(&pcs->lock);
> + mask = pcs->read(pcswi->reg);
> + if (enable)
> + mask &= ~soc_mask;
> + else
> + mask |= soc_mask;
> + pcs->write(mask, pcswi->reg);
> + raw_spin_unlock(&pcs->lock);
> + }
> +}
> +
> +/**
> + * pcs_irq_mask() - mask pinctrl interrupt
> + * @d: interrupt data
> + */
> +static void pcs_irq_mask(struct irq_data *d)
> +{
> + struct pcs_soc_data *pcs_soc = irq_data_get_irq_chip_data(d);
> +
> + pcs_irq_set(pcs_soc, d->irq, false);
> +}
> +
> +/**
> + * pcs_irq_unmask() - unmask pinctrl interrupt
> + * @d: interrupt data
> + */
> +static void pcs_irq_unmask(struct irq_data *d)
> +{
> + struct pcs_soc_data *pcs_soc = irq_data_get_irq_chip_data(d);
> +
> + pcs_irq_set(pcs_soc, d->irq, true);
> +}
> +
> +/**
> + * pcs_irq_set_wake() - toggle the suspend and resume wake up
> + * @d: interrupt data
> + * @state: wake-up state
> + *
> + * Note that this should be called only for suspend and resume.
> + * For runtime PM, the wake-up events should be enabled by default.
> + */
> +static int pcs_irq_set_wake(struct irq_data *d, unsigned int state)
> +{
> + if (state)
> + pcs_irq_unmask(d);
> + else
> + pcs_irq_mask(d);
> +
> + return 0;
> +}
> +
I tried testing this with the USB EHCI driver, but I'm not getting wake up interrupts
while the system is still running and only the EHCI controller is runtime suspended.
It seems we need to somehow call _reconfigure_io_chain() to update the daisy chain
whenever the pad wakeup_enable bit is changed.
I think pcs_irq_set_wake() is where need to control system wakeup behaviour for the irq.
This is where we should be able to change WAKEUP_EN bit of the pad
to enable/disable system wakeup for that pad and also call _reconfigure_io_chain().
This would mean that we don't really need to set WAKEUP_EN for the pads in the DTS file.
cheers,
-roger
^ permalink raw reply [flat|nested] 46+ messages in thread* [PATCH 4/6] pinctrl: single: Add support for wake-up interrupts
2013-10-10 13:24 ` Roger Quadros
@ 2013-10-10 14:04 ` Linus Walleij
2013-10-10 14:35 ` Roger Quadros
2013-10-10 16:00 ` Tony Lindgren
1 sibling, 1 reply; 46+ messages in thread
From: Linus Walleij @ 2013-10-10 14:04 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, Oct 10, 2013 at 3:24 PM, Roger Quadros <rogerq@ti.com> wrote:
> I think pcs_irq_set_wake() is where need to control system wakeup behaviour for the irq.
> This is where we should be able to change WAKEUP_EN bit of the pad
> to enable/disable system wakeup for that pad and also call _reconfigure_io_chain().
As an innocent bystander who has no clue what the _reconfigure_io_chain()
is about can you tell me what this is all about?
Is this another one of the OMAP forked paths where you must call back into
the machine with a special callback from each and every driver?
Yours,
Linus Walleij
^ permalink raw reply [flat|nested] 46+ messages in thread
* [PATCH 4/6] pinctrl: single: Add support for wake-up interrupts
2013-10-10 14:04 ` Linus Walleij
@ 2013-10-10 14:35 ` Roger Quadros
2013-10-10 15:32 ` Linus Walleij
0 siblings, 1 reply; 46+ messages in thread
From: Roger Quadros @ 2013-10-10 14:35 UTC (permalink / raw)
To: linux-arm-kernel
On 10/10/2013 05:04 PM, Linus Walleij wrote:
> On Thu, Oct 10, 2013 at 3:24 PM, Roger Quadros <rogerq@ti.com> wrote:
>
>> I think pcs_irq_set_wake() is where need to control system wakeup behaviour for the irq.
>> This is where we should be able to change WAKEUP_EN bit of the pad
>> to enable/disable system wakeup for that pad and also call _reconfigure_io_chain().
>
> As an innocent bystander who has no clue what the _reconfigure_io_chain()
> is about can you tell me what this is all about?
The OMAP SoC has a mechanism to monitor and wakeup from a low power state by creating
an IO ring of all the pads. But there is one bit in one of the control registers that
needs to be toggled each time the pad configuration is changed to re-arm the IO ring.
This is exactly what _reconfigure_io_chain() does.
>
> Is this another one of the OMAP forked paths where you must call back into
> the machine with a special callback from each and every driver?
_reconfigure_io_chain() is not available for public use and is not called by any driver yet.
However, it somehow needs to be called from this pinctrl-single driver each time the
wakeup configuration for any pad is changed.
cheers,
-roger
^ permalink raw reply [flat|nested] 46+ messages in thread
* [PATCH 4/6] pinctrl: single: Add support for wake-up interrupts
2013-10-10 14:35 ` Roger Quadros
@ 2013-10-10 15:32 ` Linus Walleij
2013-10-10 16:15 ` Tony Lindgren
0 siblings, 1 reply; 46+ messages in thread
From: Linus Walleij @ 2013-10-10 15:32 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, Oct 10, 2013 at 4:35 PM, Roger Quadros <rogerq@ti.com> wrote:
> On 10/10/2013 05:04 PM, Linus Walleij wrote:
>> As an innocent bystander who has no clue what the _reconfigure_io_chain()
>> is about can you tell me what this is all about?
>
> The OMAP SoC has a mechanism to monitor and wakeup from a low power state by creating
> an IO ring of all the pads. But there is one bit in one of the control registers that
> needs to be toggled each time the pad configuration is changed to re-arm the IO ring.
> This is exactly what _reconfigure_io_chain() does.
OK I get it, I checked the function in the machone.
>> Is this another one of the OMAP forked paths where you must call back into
>> the machine with a special callback from each and every driver?
>
> _reconfigure_io_chain() is not available for public use and is not called by any driver yet.
> However, it somehow needs to be called from this pinctrl-single driver each time the
> wakeup configuration for any pad is changed.
Actually this is one of those things where the complexity of the platform
seems to start to leak into the nice picture of one-register-per-pin.
If this was *not* pinctrl-single but pinctrl-omap.c, it would make sense to
move this _reconfigure_io code and the PRM registers it is touching down
into the pinctrl driver, because it seems like absolutely no-one else
is using it.
Both the other occurences seem to be in omap_hwmod.c, and seems
to be related to pin muxing, which is now supposed to be handled by
the pin control driver, right?
I think the real solution to this would be something like:
- Add the compatible strings "pinctrl-single-omap3" and
"pinctrl-single-omap4" to drivers/pinctrl/pinctrl-single.c,
- Pass an additional <&ersand> resource for the prm
thing to the single driver in the OMAP platform.
- Move this _reconfigure_io code out of the mach-omap2
machines and hwmod and down into the pinctrl-single driver,
it can be #ifdef ARCH_OMAP with stubs or whatever, the
important thing is that it lives with the pinctrl driver.
This does the right thing and let the pinctrl driver handle the io ring,
instead of artificially trying to hide that in the mach-omap2 directory
which is only creating a mess of things.
I know this is sort of breaking the promise of pinctrl-single.c only
handling single registers but we just need to accept the fact that
if this idea is not perfect, trying to hide the facts of life isn't any
good either.
What do you say about this Tony? Good/bad/Linus is a moron? ;-)
Yours,
Linus Walleij
^ permalink raw reply [flat|nested] 46+ messages in thread
* [PATCH 4/6] pinctrl: single: Add support for wake-up interrupts
2013-10-10 15:32 ` Linus Walleij
@ 2013-10-10 16:15 ` Tony Lindgren
0 siblings, 0 replies; 46+ messages in thread
From: Tony Lindgren @ 2013-10-10 16:15 UTC (permalink / raw)
To: linux-arm-kernel
* Linus Walleij <linus.walleij@linaro.org> [131010 08:40]:
> On Thu, Oct 10, 2013 at 4:35 PM, Roger Quadros <rogerq@ti.com> wrote:
> > On 10/10/2013 05:04 PM, Linus Walleij wrote:
>
> >> As an innocent bystander who has no clue what the _reconfigure_io_chain()
> >> is about can you tell me what this is all about?
> >
> > The OMAP SoC has a mechanism to monitor and wakeup from a low power state by creating
> > an IO ring of all the pads. But there is one bit in one of the control registers that
> > needs to be toggled each time the pad configuration is changed to re-arm the IO ring.
> > This is exactly what _reconfigure_io_chain() does.
>
> OK I get it, I checked the function in the machone.
>
> >> Is this another one of the OMAP forked paths where you must call back into
> >> the machine with a special callback from each and every driver?
> >
> > _reconfigure_io_chain() is not available for public use and is not called by any driver yet.
> > However, it somehow needs to be called from this pinctrl-single driver each time the
> > wakeup configuration for any pad is changed.
>
> Actually this is one of those things where the complexity of the platform
> seems to start to leak into the nice picture of one-register-per-pin.
>
> If this was *not* pinctrl-single but pinctrl-omap.c, it would make sense to
> move this _reconfigure_io code and the PRM registers it is touching down
> into the pinctrl driver, because it seems like absolutely no-one else
> is using it.
>
> Both the other occurences seem to be in omap_hwmod.c, and seems
> to be related to pin muxing, which is now supposed to be handled by
> the pin control driver, right?
Right, that's for the legacy muxing code. With the legacy code we know
the device using the pins and it's interrupt in the hwmod code, so
transparent handling of the runtime PM wake-up events is easy. But that
is at the cost of huge data tables for every SoC variant, which is what
we're trying to avoid here.
> I think the real solution to this would be something like:
>
> - Add the compatible strings "pinctrl-single-omap3" and
> "pinctrl-single-omap4" to drivers/pinctrl/pinctrl-single.c,
>
> - Pass an additional <&ersand> resource for the prm
> thing to the single driver in the OMAP platform.
>
> - Move this _reconfigure_io code out of the mach-omap2
> machines and hwmod and down into the pinctrl-single driver,
> it can be #ifdef ARCH_OMAP with stubs or whatever, the
> important thing is that it lives with the pinctrl driver.
>
> This does the right thing and let the pinctrl driver handle the io ring,
> instead of artificially trying to hide that in the mach-omap2 directory
> which is only creating a mess of things.
>
> I know this is sort of breaking the promise of pinctrl-single.c only
> handling single registers but we just need to accept the fact that
> if this idea is not perfect, trying to hide the facts of life isn't any
> good either.
>
> What do you say about this Tony? Good/bad/Linus is a moron? ;-)
Yes once we have made omap3 to be DT only, a lot of the legacy mux stuff
will clear out. And at that point we can start moving things into PRCM
drivers to handle the single shared wake-up interrupt that PRM and also
pinctrl-single is using.
However, the reconfigure_io_chain() registers are in the PRM module, so
it still should be the PRM driver managing it rather than pinctrl-single
that's in the SCM module as they can at least in theory live a separate
power state lifes. But in any case, things will get simpler once the
dependencies to the legacy code are cut.
Regards,
Tony
^ permalink raw reply [flat|nested] 46+ messages in thread
* [PATCH 4/6] pinctrl: single: Add support for wake-up interrupts
2013-10-10 13:24 ` Roger Quadros
2013-10-10 14:04 ` Linus Walleij
@ 2013-10-10 16:00 ` Tony Lindgren
2013-10-10 16:11 ` Linus Walleij
` (2 more replies)
1 sibling, 3 replies; 46+ messages in thread
From: Tony Lindgren @ 2013-10-10 16:00 UTC (permalink / raw)
To: linux-arm-kernel
* Roger Quadros <rogerq@ti.com> [131010 06:32]:
>
> I tried testing this with the USB EHCI driver, but I'm not getting wake up interrupts
> while the system is still running and only the EHCI controller is runtime suspended.
>
> It seems we need to somehow call _reconfigure_io_chain() to update the daisy chain
> whenever the pad wakeup_enable bit is changed.
Sounds like this is on omap3? Have you tried calling pcs_soc->rearm() in the
pcs_irq_handle() like the comments there suggest? At least for me that keeps
the wake-up interrupts continuously running on omap3 instead of just idle modes.
Now on omap4, I've noticed the wake up interrupts are on all the time based on tests
with the serial driver.
> I think pcs_irq_set_wake() is where need to control system wakeup behaviour for the irq.
> This is where we should be able to change WAKEUP_EN bit of the pad
> to enable/disable system wakeup for that pad and also call _reconfigure_io_chain().
Well the irq_set_wake() should only be needed for suspend and resume. For runtime PM
the wake-events should be always enabled by default as pointed out by Alan Stern
a while back.
> This would mean that we don't really need to set WAKEUP_EN for the pads in the DTS file.
Well for runtime PM, we should also do the automatic handling if configured.
But how to do that best is still open..
Regards,
Tony
^ permalink raw reply [flat|nested] 46+ messages in thread* [PATCH 4/6] pinctrl: single: Add support for wake-up interrupts
2013-10-10 16:00 ` Tony Lindgren
@ 2013-10-10 16:11 ` Linus Walleij
2013-10-10 16:20 ` Tony Lindgren
2013-10-10 16:23 ` Tony Lindgren
2013-10-11 8:49 ` Roger Quadros
2 siblings, 1 reply; 46+ messages in thread
From: Linus Walleij @ 2013-10-10 16:11 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, Oct 10, 2013 at 6:00 PM, Tony Lindgren <tony@atomide.com> wrote:
> * Roger Quadros <rogerq@ti.com> [131010 06:32]:
>>
>> I tried testing this with the USB EHCI driver, but I'm not getting wake up interrupts
>> while the system is still running and only the EHCI controller is runtime suspended.
>>
>> It seems we need to somehow call _reconfigure_io_chain() to update the daisy chain
>> whenever the pad wakeup_enable bit is changed.
>
> Sounds like this is on omap3? Have you tried calling pcs_soc->rearm() in the
> pcs_irq_handle() like the comments there suggest? At least for me that keeps
> the wake-up interrupts continuously running on omap3 instead of just idle modes.
If the rearm() function is calling this _reconfigure_io_chain my comments
on the fact that this is something that should be handled by the pin
control driver still apply I think ....
Yours,
Linus Walleij
^ permalink raw reply [flat|nested] 46+ messages in thread
* [PATCH 4/6] pinctrl: single: Add support for wake-up interrupts
2013-10-10 16:11 ` Linus Walleij
@ 2013-10-10 16:20 ` Tony Lindgren
2013-10-11 8:00 ` Linus Walleij
0 siblings, 1 reply; 46+ messages in thread
From: Tony Lindgren @ 2013-10-10 16:20 UTC (permalink / raw)
To: linux-arm-kernel
* Linus Walleij <linus.walleij@linaro.org> [131010 09:19]:
> On Thu, Oct 10, 2013 at 6:00 PM, Tony Lindgren <tony@atomide.com> wrote:
> > * Roger Quadros <rogerq@ti.com> [131010 06:32]:
> >>
> >> I tried testing this with the USB EHCI driver, but I'm not getting wake up interrupts
> >> while the system is still running and only the EHCI controller is runtime suspended.
> >>
> >> It seems we need to somehow call _reconfigure_io_chain() to update the daisy chain
> >> whenever the pad wakeup_enable bit is changed.
> >
> > Sounds like this is on omap3? Have you tried calling pcs_soc->rearm() in the
> > pcs_irq_handle() like the comments there suggest? At least for me that keeps
> > the wake-up interrupts continuously running on omap3 instead of just idle modes.
>
> If the rearm() function is calling this _reconfigure_io_chain my comments
> on the fact that this is something that should be handled by the pin
> control driver still apply I think ....
Yes, except that the reconfigure_io_chain registers are in the PRM module, not in
the SCM module where the pinctrl registers are.. And that shared PRM interrupt is
used mostly for the internal domain wake-ups, so we should keep that in the PRM
driver.
Regards,
Tony
^ permalink raw reply [flat|nested] 46+ messages in thread
* [PATCH 4/6] pinctrl: single: Add support for wake-up interrupts
2013-10-10 16:20 ` Tony Lindgren
@ 2013-10-11 8:00 ` Linus Walleij
2013-10-11 8:56 ` Roger Quadros
0 siblings, 1 reply; 46+ messages in thread
From: Linus Walleij @ 2013-10-11 8:00 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, Oct 10, 2013 at 6:20 PM, Tony Lindgren <tony@atomide.com> wrote:
> * Linus Walleij <linus.walleij@linaro.org> [131010 09:19]:
>> On Thu, Oct 10, 2013 at 6:00 PM, Tony Lindgren <tony@atomide.com> wrote:
>> > * Roger Quadros <rogerq@ti.com> [131010 06:32]:
>> >>
>> >> I tried testing this with the USB EHCI driver, but I'm not getting wake up interrupts
>> >> while the system is still running and only the EHCI controller is runtime suspended.
>> >>
>> >> It seems we need to somehow call _reconfigure_io_chain() to update the daisy chain
>> >> whenever the pad wakeup_enable bit is changed.
>> >
>> > Sounds like this is on omap3? Have you tried calling pcs_soc->rearm() in the
>> > pcs_irq_handle() like the comments there suggest? At least for me that keeps
>> > the wake-up interrupts continuously running on omap3 instead of just idle modes.
>>
>> If the rearm() function is calling this _reconfigure_io_chain my comments
>> on the fact that this is something that should be handled by the pin
>> control driver still apply I think ....
>
> Yes, except that the reconfigure_io_chain registers are in the PRM module, not in
> the SCM module where the pinctrl registers are.. And that shared PRM interrupt is
> used mostly for the internal domain wake-ups, so we should keep that in the PRM
> driver.
That depends.
One-iorange-equals-one-driver is a fallacy, especially given that MFD for
memory-mapped things exist for a reason.
What the pin control driver should do is control the pins. Whether the registers
are spread out in the entire IO-memory does not matter. We did have one system
which placed the IO-muxing together with each peripheral (!) and I did
still want
that to be handled by a single pinctrl driver picking out windows to all these
IO-ranges.
Things like the PRM which has (my guess) a gazillion registers related to its
deep-core SoC stuff should be handled by things like
drivers/mfd/syscon.c, which means it is dead simple for some other driver
using "just this one register" in that range to get a handle at it and poke it
using syscon_node_to_regmap() (just derference an ampersand ref)
syscon_regmap_lookup_by_compatible() (use a compatible string)
all returning a regmap * that you can use to poke these registers.
Yours,
Linus Walleij
^ permalink raw reply [flat|nested] 46+ messages in thread
* [PATCH 4/6] pinctrl: single: Add support for wake-up interrupts
2013-10-11 8:00 ` Linus Walleij
@ 2013-10-11 8:56 ` Roger Quadros
2013-10-11 10:32 ` Linus Walleij
2013-10-11 15:36 ` Tony Lindgren
0 siblings, 2 replies; 46+ messages in thread
From: Roger Quadros @ 2013-10-11 8:56 UTC (permalink / raw)
To: linux-arm-kernel
On 10/11/2013 11:00 AM, Linus Walleij wrote:
> On Thu, Oct 10, 2013 at 6:20 PM, Tony Lindgren <tony@atomide.com> wrote:
>> * Linus Walleij <linus.walleij@linaro.org> [131010 09:19]:
>>> On Thu, Oct 10, 2013 at 6:00 PM, Tony Lindgren <tony@atomide.com> wrote:
>>>> * Roger Quadros <rogerq@ti.com> [131010 06:32]:
>>>>>
>>>>> I tried testing this with the USB EHCI driver, but I'm not getting wake up interrupts
>>>>> while the system is still running and only the EHCI controller is runtime suspended.
>>>>>
>>>>> It seems we need to somehow call _reconfigure_io_chain() to update the daisy chain
>>>>> whenever the pad wakeup_enable bit is changed.
>>>>
>>>> Sounds like this is on omap3? Have you tried calling pcs_soc->rearm() in the
>>>> pcs_irq_handle() like the comments there suggest? At least for me that keeps
>>>> the wake-up interrupts continuously running on omap3 instead of just idle modes.
>>>
>>> If the rearm() function is calling this _reconfigure_io_chain my comments
>>> on the fact that this is something that should be handled by the pin
>>> control driver still apply I think ....
>>
>> Yes, except that the reconfigure_io_chain registers are in the PRM module, not in
>> the SCM module where the pinctrl registers are.. And that shared PRM interrupt is
>> used mostly for the internal domain wake-ups, so we should keep that in the PRM
>> driver.
>
> That depends.
>
> One-iorange-equals-one-driver is a fallacy, especially given that MFD for
> memory-mapped things exist for a reason.
+1
Another place I faced a similar problem was the OMAP control module, which contains
registers for a number of different non related peripherals. (e.g. PHY for USB, SATA,
Display clock, etc)
>
> What the pin control driver should do is control the pins. Whether the registers
> are spread out in the entire IO-memory does not matter. We did have one system
> which placed the IO-muxing together with each peripheral (!) and I did
> still want
> that to be handled by a single pinctrl driver picking out windows to all these
> IO-ranges.
>
> Things like the PRM which has (my guess) a gazillion registers related to its
> deep-core SoC stuff should be handled by things like
> drivers/mfd/syscon.c, which means it is dead simple for some other driver
> using "just this one register" in that range to get a handle at it and poke it
> using syscon_node_to_regmap() (just derference an ampersand ref)
> syscon_regmap_lookup_by_compatible() (use a compatible string)
> all returning a regmap * that you can use to poke these registers.
The register handling is fine. But how do we deal with resource handling?
e.g. the block that has the deep-core registers might need to be clocked or powered
before the registers can be accessed.
cheers,
-roger
^ permalink raw reply [flat|nested] 46+ messages in thread
* [PATCH 4/6] pinctrl: single: Add support for wake-up interrupts
2013-10-11 8:56 ` Roger Quadros
@ 2013-10-11 10:32 ` Linus Walleij
2013-10-11 15:43 ` Tony Lindgren
2013-10-11 15:36 ` Tony Lindgren
1 sibling, 1 reply; 46+ messages in thread
From: Linus Walleij @ 2013-10-11 10:32 UTC (permalink / raw)
To: linux-arm-kernel
On Fri, Oct 11, 2013 at 10:56 AM, Roger Quadros <rogerq@ti.com> wrote:
> The register handling is fine. But how do we deal with resource handling?
> e.g. the block that has the deep-core registers might need to be clocked or powered
> before the registers can be accessed.
Yeah I saw this in the code there.
In this case it seems syscon-type regmap access can be used to
read/write the registers, so maybe the pin controller also need to
get a handle on some clock etc?
The general idea is however that large monolitic "drivers" for a
certain IO-range such as arch/arm/mach-omap2/prm3xxx.c
doesn't scale - we saw this with the Ux500 PRCMU driver in
mfd/* to the point that our patches to extend it were NACK:ed
until we refactor it. This stuff in mach-omap2 is in the same bad
design pattern, and need to get out of it.
The approach chosen for the Ux500 PRCMU was to distribute
out the driver into the places where it's actually used, like the
clock driver etc. The accessor functions to do some stuff over
in the PRCMU was just adding a layer of cruft.
Yours,
Linus Walleij
^ permalink raw reply [flat|nested] 46+ messages in thread
* [PATCH 4/6] pinctrl: single: Add support for wake-up interrupts
2013-10-11 10:32 ` Linus Walleij
@ 2013-10-11 15:43 ` Tony Lindgren
2013-10-11 15:56 ` Linus Walleij
0 siblings, 1 reply; 46+ messages in thread
From: Tony Lindgren @ 2013-10-11 15:43 UTC (permalink / raw)
To: linux-arm-kernel
* Linus Walleij <linus.walleij@linaro.org> [131011 03:40]:
> On Fri, Oct 11, 2013 at 10:56 AM, Roger Quadros <rogerq@ti.com> wrote:
>
> > The register handling is fine. But how do we deal with resource handling?
> > e.g. the block that has the deep-core registers might need to be clocked or powered
> > before the registers can be accessed.
>
> Yeah I saw this in the code there.
>
> In this case it seems syscon-type regmap access can be used to
> read/write the registers, so maybe the pin controller also need to
> get a handle on some clock etc?
Uhh, let's not go there.. The resource availability needs to be
handled transparently in regmap code and the reg provider hardware
module driver using runtime PM.
> The general idea is however that large monolitic "drivers" for a
> certain IO-range such as arch/arm/mach-omap2/prm3xxx.c
> doesn't scale - we saw this with the Ux500 PRCMU driver in
> mfd/* to the point that our patches to extend it were NACK:ed
> until we refactor it. This stuff in mach-omap2 is in the same bad
> design pattern, and need to get out of it.
>
> The approach chosen for the Ux500 PRCMU was to distribute
> out the driver into the places where it's actually used, like the
> clock driver etc. The accessor functions to do some stuff over
> in the PRCMU was just adding a layer of cruft.
Yes I'm all in favor of having a minimal PRM core driver that manages
resources and provides register access services in a controlled way
to it's client drivers. As long as the emphasis is "in a controlled
way".
Regards,
Tony
^ permalink raw reply [flat|nested] 46+ messages in thread
* [PATCH 4/6] pinctrl: single: Add support for wake-up interrupts
2013-10-11 15:43 ` Tony Lindgren
@ 2013-10-11 15:56 ` Linus Walleij
2013-10-11 16:01 ` Tony Lindgren
0 siblings, 1 reply; 46+ messages in thread
From: Linus Walleij @ 2013-10-11 15:56 UTC (permalink / raw)
To: linux-arm-kernel
On Fri, Oct 11, 2013 at 5:43 PM, Tony Lindgren <tony@atomide.com> wrote:
> * Linus Walleij <linus.walleij@linaro.org> [131011 03:40]:
>> On Fri, Oct 11, 2013 at 10:56 AM, Roger Quadros <rogerq@ti.com> wrote:
>>
>> > The register handling is fine. But how do we deal with resource handling?
>> > e.g. the block that has the deep-core registers might need to be clocked or powered
>> > before the registers can be accessed.
>>
>> Yeah I saw this in the code there.
>>
>> In this case it seems syscon-type regmap access can be used to
>> read/write the registers, so maybe the pin controller also need to
>> get a handle on some clock etc?
>
> Uhh, let's not go there.. The resource availability needs to be
> handled transparently in regmap code and the reg provider hardware
> module driver using runtime PM.
OK we can surely discuss this with broonie, it makes sense to
have regmap be able to do its deed transparently.
Yours,
Linus Walleij
^ permalink raw reply [flat|nested] 46+ messages in thread
* [PATCH 4/6] pinctrl: single: Add support for wake-up interrupts
2013-10-11 15:56 ` Linus Walleij
@ 2013-10-11 16:01 ` Tony Lindgren
2013-10-18 7:40 ` Balaji T K
0 siblings, 1 reply; 46+ messages in thread
From: Tony Lindgren @ 2013-10-11 16:01 UTC (permalink / raw)
To: linux-arm-kernel
* Linus Walleij <linus.walleij@linaro.org> [131011 09:05]:
> On Fri, Oct 11, 2013 at 5:43 PM, Tony Lindgren <tony@atomide.com> wrote:
> > * Linus Walleij <linus.walleij@linaro.org> [131011 03:40]:
> >> On Fri, Oct 11, 2013 at 10:56 AM, Roger Quadros <rogerq@ti.com> wrote:
> >>
> >> > The register handling is fine. But how do we deal with resource handling?
> >> > e.g. the block that has the deep-core registers might need to be clocked or powered
> >> > before the registers can be accessed.
> >>
> >> Yeah I saw this in the code there.
> >>
> >> In this case it seems syscon-type regmap access can be used to
> >> read/write the registers, so maybe the pin controller also need to
> >> get a handle on some clock etc?
> >
> > Uhh, let's not go there.. The resource availability needs to be
> > handled transparently in regmap code and the reg provider hardware
> > module driver using runtime PM.
>
> OK we can surely discuss this with broonie, it makes sense to
> have regmap be able to do its deed transparently.
Yes I think so too. Sounds like we need callbacks for the runtime PM
checks to the "register provider" driver. Hwo knows, maybe those
features are there already :)
Tony
^ permalink raw reply [flat|nested] 46+ messages in thread
* [PATCH 4/6] pinctrl: single: Add support for wake-up interrupts
2013-10-11 16:01 ` Tony Lindgren
@ 2013-10-18 7:40 ` Balaji T K
2013-10-18 15:35 ` Tony Lindgren
0 siblings, 1 reply; 46+ messages in thread
From: Balaji T K @ 2013-10-18 7:40 UTC (permalink / raw)
To: linux-arm-kernel
On Friday 11 October 2013 09:31 PM, Tony Lindgren wrote:
> * Linus Walleij <linus.walleij@linaro.org> [131011 09:05]:
>> On Fri, Oct 11, 2013 at 5:43 PM, Tony Lindgren <tony@atomide.com> wrote:
>>> * Linus Walleij <linus.walleij@linaro.org> [131011 03:40]:
>>>> On Fri, Oct 11, 2013 at 10:56 AM, Roger Quadros <rogerq@ti.com> wrote:
>>>>
>>>>> The register handling is fine. But how do we deal with resource handling?
>>>>> e.g. the block that has the deep-core registers might need to be clocked or powered
>>>>> before the registers can be accessed.
>>>>
>>>> Yeah I saw this in the code there.
>>>>
>>>> In this case it seems syscon-type regmap access can be used to
>>>> read/write the registers, so maybe the pin controller also need to
>>>> get a handle on some clock etc?
>>>
>>> Uhh, let's not go there.. The resource availability needs to be
>>> handled transparently in regmap code and the reg provider hardware
>>> module driver using runtime PM.
>>
>> OK we can surely discuss this with broonie, it makes sense to
>> have regmap be able to do its deed transparently.
>
> Yes I think so too. Sounds like we need callbacks for the runtime PM
> checks to the "register provider" driver. Hwo knows, maybe those
> features are there already :)
>
Hi Tony,
Any conclusion on using regmap for omap control module non-mux registers ?
Thanks and Regards,
Balaji T K
^ permalink raw reply [flat|nested] 46+ messages in thread
* [PATCH 4/6] pinctrl: single: Add support for wake-up interrupts
2013-10-18 7:40 ` Balaji T K
@ 2013-10-18 15:35 ` Tony Lindgren
2013-10-18 15:59 ` Balaji T K
0 siblings, 1 reply; 46+ messages in thread
From: Tony Lindgren @ 2013-10-18 15:35 UTC (permalink / raw)
To: linux-arm-kernel
* Balaji T K <balajitk@ti.com> [131018 00:41]:
>
> Any conclusion on using regmap for omap control module non-mux registers ?
I don't think anybody has even started looking into a SCM driver
yet considering there are tons of other issues to sort out.
If you're thinking about implementing the MMC PBIAS driver, I would
just implement it as a standalone driver. It seems that the PBIAS
interface to the MMC driver can be just regulator framework.
Then when we have the SCM driver available, this driver can be
updated to coordinate things with the core SCM driver.
Regards,
Tony
^ permalink raw reply [flat|nested] 46+ messages in thread
* [PATCH 4/6] pinctrl: single: Add support for wake-up interrupts
2013-10-18 15:35 ` Tony Lindgren
@ 2013-10-18 15:59 ` Balaji T K
2013-10-18 16:06 ` Tony Lindgren
0 siblings, 1 reply; 46+ messages in thread
From: Balaji T K @ 2013-10-18 15:59 UTC (permalink / raw)
To: linux-arm-kernel
On Friday 18 October 2013 09:05 PM, Tony Lindgren wrote:
> * Balaji T K <balajitk@ti.com> [131018 00:41]:
>>
>> Any conclusion on using regmap for omap control module non-mux registers ?
>
> I don't think anybody has even started looking into a SCM driver
> yet considering there are tons of other issues to sort out.
>
> If you're thinking about implementing the MMC PBIAS driver, I would
> just implement it as a standalone driver. It seems that the PBIAS
> interface to the MMC driver can be just regulator framework.
>
Hi Tony,
I am testing pbias regulator, Just thinking whether it should be
using regmap api or direct readl/writel
> Then when we have the SCM driver available, this driver can be
> updated to coordinate things with the core SCM driver.
Do you see regmap getting used for the SCM driver ?
Thanks and Regards,
Balaji T K
>
> Regards,
>
> Tony
>
^ permalink raw reply [flat|nested] 46+ messages in thread
* [PATCH 4/6] pinctrl: single: Add support for wake-up interrupts
2013-10-18 15:59 ` Balaji T K
@ 2013-10-18 16:06 ` Tony Lindgren
0 siblings, 0 replies; 46+ messages in thread
From: Tony Lindgren @ 2013-10-18 16:06 UTC (permalink / raw)
To: linux-arm-kernel
* Balaji T K <balajitk@ti.com> [131018 08:59]:
> On Friday 18 October 2013 09:05 PM, Tony Lindgren wrote:
> >* Balaji T K <balajitk@ti.com> [131018 00:41]:
> >>
> >>Any conclusion on using regmap for omap control module non-mux registers ?
> >
> >I don't think anybody has even started looking into a SCM driver
> >yet considering there are tons of other issues to sort out.
> >
> >If you're thinking about implementing the MMC PBIAS driver, I would
> >just implement it as a standalone driver. It seems that the PBIAS
> >interface to the MMC driver can be just regulator framework.
> >
> Hi Tony,
>
> I am testing pbias regulator, Just thinking whether it should be
> using regmap api or direct readl/writel
OK either or should work. It seems that can easily be changed
later on though.
> >Then when we have the SCM driver available, this driver can be
> >updated to coordinate things with the core SCM driver.
>
> Do you see regmap getting used for the SCM driver ?
Yes eventually :)
Tony
^ permalink raw reply [flat|nested] 46+ messages in thread
* [PATCH 4/6] pinctrl: single: Add support for wake-up interrupts
2013-10-11 8:56 ` Roger Quadros
2013-10-11 10:32 ` Linus Walleij
@ 2013-10-11 15:36 ` Tony Lindgren
2013-10-11 15:43 ` Balaji T K
1 sibling, 1 reply; 46+ messages in thread
From: Tony Lindgren @ 2013-10-11 15:36 UTC (permalink / raw)
To: linux-arm-kernel
* Roger Quadros <rogerq@ti.com> [131011 02:04]:
> On 10/11/2013 11:00 AM, Linus Walleij wrote:
> > On Thu, Oct 10, 2013 at 6:20 PM, Tony Lindgren <tony@atomide.com> wrote:
> >> * Linus Walleij <linus.walleij@linaro.org> [131010 09:19]:
> >>> On Thu, Oct 10, 2013 at 6:00 PM, Tony Lindgren <tony@atomide.com> wrote:
> >>>> * Roger Quadros <rogerq@ti.com> [131010 06:32]:
> >>>>>
> >>>>> I tried testing this with the USB EHCI driver, but I'm not getting wake up interrupts
> >>>>> while the system is still running and only the EHCI controller is runtime suspended.
> >>>>>
> >>>>> It seems we need to somehow call _reconfigure_io_chain() to update the daisy chain
> >>>>> whenever the pad wakeup_enable bit is changed.
> >>>>
> >>>> Sounds like this is on omap3? Have you tried calling pcs_soc->rearm() in the
> >>>> pcs_irq_handle() like the comments there suggest? At least for me that keeps
> >>>> the wake-up interrupts continuously running on omap3 instead of just idle modes.
> >>>
> >>> If the rearm() function is calling this _reconfigure_io_chain my comments
> >>> on the fact that this is something that should be handled by the pin
> >>> control driver still apply I think ....
> >>
> >> Yes, except that the reconfigure_io_chain registers are in the PRM module, not in
> >> the SCM module where the pinctrl registers are.. And that shared PRM interrupt is
> >> used mostly for the internal domain wake-ups, so we should keep that in the PRM
> >> driver.
> >
> > That depends.
> >
> > One-iorange-equals-one-driver is a fallacy, especially given that MFD for
> > memory-mapped things exist for a reason.
>
> +1
>
> Another place I faced a similar problem was the OMAP control module, which contains
> registers for a number of different non related peripherals. (e.g. PHY for USB, SATA,
> Display clock, etc)
Guys, we really need to keep the register access between hardware modules
under control because the hardware blocks can live separate life from clocking
and power state point of view.
Regmap could be probably used for the register access across various hardware
modules in a controlled way that is also aware of the clocking and PM state of
the hardware modules in question. As long as it's done sanely, I'm OK with that.
But for any other kind of random direct register tinkering between hardware
modules, that's a no no.
> > What the pin control driver should do is control the pins. Whether the registers
> > are spread out in the entire IO-memory does not matter. We did have one system
> > which placed the IO-muxing together with each peripheral (!) and I did
> > still want
> > that to be handled by a single pinctrl driver picking out windows to all these
> > IO-ranges.
> >
> > Things like the PRM which has (my guess) a gazillion registers related to its
> > deep-core SoC stuff should be handled by things like
> > drivers/mfd/syscon.c, which means it is dead simple for some other driver
> > using "just this one register" in that range to get a handle at it and poke it
> > using syscon_node_to_regmap() (just derference an ampersand ref)
> > syscon_regmap_lookup_by_compatible() (use a compatible string)
> > all returning a regmap * that you can use to poke these registers.
>
> The register handling is fine. But how do we deal with resource handling?
> e.g. the block that has the deep-core registers might need to be clocked or powered
> before the registers can be accessed.
Right, that's the key issue here. The register access would have to be conditional
based on the hardware modules PM state. Otherwise we'll have hard to trace hangs
and oopses.
Regards,
Tony
^ permalink raw reply [flat|nested] 46+ messages in thread
* [PATCH 4/6] pinctrl: single: Add support for wake-up interrupts
2013-10-11 15:36 ` Tony Lindgren
@ 2013-10-11 15:43 ` Balaji T K
2013-10-11 15:48 ` Tony Lindgren
0 siblings, 1 reply; 46+ messages in thread
From: Balaji T K @ 2013-10-11 15:43 UTC (permalink / raw)
To: linux-arm-kernel
On Friday 11 October 2013 09:06 PM, Tony Lindgren wrote:
>>> What the pin control driver should do is control the pins. Whether the registers
>>> are spread out in the entire IO-memory does not matter. We did have one system
>>> which placed the IO-muxing together with each peripheral (!) and I did
>>> still want
>>> that to be handled by a single pinctrl driver picking out windows to all these
>>> IO-ranges.
>>>
>>> Things like the PRM which has (my guess) a gazillion registers related to its
>>> deep-core SoC stuff should be handled by things like
>>> drivers/mfd/syscon.c, which means it is dead simple for some other driver
>>> using "just this one register" in that range to get a handle at it and poke it
>>> using syscon_node_to_regmap() (just derference an ampersand ref)
>>> syscon_regmap_lookup_by_compatible() (use a compatible string)
>>> all returning a regmap * that you can use to poke these registers.
>>
>> The register handling is fine. But how do we deal with resource handling?
>> e.g. the block that has the deep-core registers might need to be clocked or powered
>> before the registers can be accessed.
>
> Right, that's the key issue here. The register access would have to be conditional
> based on the hardware modules PM state. Otherwise we'll have hard to trace hangs
> and oopses.
>
Hi Tony,
How are the clocks/power state currently handled in case of omap4_pmx_core,
omap4_pmx_wkup register access via pinctrl-single ?
Thanks and Regards,
Balaji T K
^ permalink raw reply [flat|nested] 46+ messages in thread
* [PATCH 4/6] pinctrl: single: Add support for wake-up interrupts
2013-10-11 15:43 ` Balaji T K
@ 2013-10-11 15:48 ` Tony Lindgren
0 siblings, 0 replies; 46+ messages in thread
From: Tony Lindgren @ 2013-10-11 15:48 UTC (permalink / raw)
To: linux-arm-kernel
* Balaji T K <balajitk@ti.com> [131011 08:51]:
> On Friday 11 October 2013 09:06 PM, Tony Lindgren wrote:
> >>>What the pin control driver should do is control the pins. Whether the registers
> >>>are spread out in the entire IO-memory does not matter. We did have one system
> >>>which placed the IO-muxing together with each peripheral (!) and I did
> >>>still want
> >>>that to be handled by a single pinctrl driver picking out windows to all these
> >>>IO-ranges.
> >>>
> >>>Things like the PRM which has (my guess) a gazillion registers related to its
> >>>deep-core SoC stuff should be handled by things like
> >>>drivers/mfd/syscon.c, which means it is dead simple for some other driver
> >>>using "just this one register" in that range to get a handle at it and poke it
> >>>using syscon_node_to_regmap() (just derference an ampersand ref)
> >>>syscon_regmap_lookup_by_compatible() (use a compatible string)
> >>>all returning a regmap * that you can use to poke these registers.
> >>
> >>The register handling is fine. But how do we deal with resource handling?
> >>e.g. the block that has the deep-core registers might need to be clocked or powered
> >>before the registers can be accessed.
> >
> >Right, that's the key issue here. The register access would have to be conditional
> >based on the hardware modules PM state. Otherwise we'll have hard to trace hangs
> >and oopses.
> >
> Hi Tony,
>
> How are the clocks/power state currently handled in case of omap4_pmx_core,
> omap4_pmx_wkup register access via pinctrl-single ?
It's currently always on during runtime and managed in for the whole SCM
by mach-omap2/control.c. Then there's a separate SCM register that triggers
the save and restore of the padconf registers in hardware for off-idle
along with other SCM related things, see the *_control_save/restore_context()
functions.
Regards,
Tony
^ permalink raw reply [flat|nested] 46+ messages in thread
* [PATCH 4/6] pinctrl: single: Add support for wake-up interrupts
2013-10-10 16:00 ` Tony Lindgren
2013-10-10 16:11 ` Linus Walleij
@ 2013-10-10 16:23 ` Tony Lindgren
2013-10-11 8:45 ` Roger Quadros
2013-10-11 8:49 ` Roger Quadros
2 siblings, 1 reply; 46+ messages in thread
From: Tony Lindgren @ 2013-10-10 16:23 UTC (permalink / raw)
To: linux-arm-kernel
* Tony Lindgren <tony@atomide.com> [131010 09:09]:
> * Roger Quadros <rogerq@ti.com> [131010 06:32]:
> >
> > I tried testing this with the USB EHCI driver, but I'm not getting wake up interrupts
> > while the system is still running and only the EHCI controller is runtime suspended.
> >
> > It seems we need to somehow call _reconfigure_io_chain() to update the daisy chain
> > whenever the pad wakeup_enable bit is changed.
>
> Sounds like this is on omap3? Have you tried calling pcs_soc->rearm() in the
> pcs_irq_handle() like the comments there suggest? At least for me that keeps
> the wake-up interrupts continuously running on omap3 instead of just idle modes.
>
> Now on omap4, I've noticed the wake up interrupts are on all the time based on tests
> with the serial driver.
Oh, and if you're runtime suspending EHCI only, and if the EHCI module has
wake-up registers, it should be able to wake EHCI from retention on it's own
without a need for the io chain at all.
At least the serial driver does that if it's internal wake-up registers are
configured right. But for off-idle, the serial driver needs the io chain wake-up
events.
Regards,
Tony
^ permalink raw reply [flat|nested] 46+ messages in thread
* [PATCH 4/6] pinctrl: single: Add support for wake-up interrupts
2013-10-10 16:23 ` Tony Lindgren
@ 2013-10-11 8:45 ` Roger Quadros
0 siblings, 0 replies; 46+ messages in thread
From: Roger Quadros @ 2013-10-11 8:45 UTC (permalink / raw)
To: linux-arm-kernel
On 10/10/2013 07:23 PM, Tony Lindgren wrote:
> * Tony Lindgren <tony@atomide.com> [131010 09:09]:
>> * Roger Quadros <rogerq@ti.com> [131010 06:32]:
>>>
>>> I tried testing this with the USB EHCI driver, but I'm not getting wake up interrupts
>>> while the system is still running and only the EHCI controller is runtime suspended.
>>>
>>> It seems we need to somehow call _reconfigure_io_chain() to update the daisy chain
>>> whenever the pad wakeup_enable bit is changed.
>>
>> Sounds like this is on omap3? Have you tried calling pcs_soc->rearm() in the
>> pcs_irq_handle() like the comments there suggest? At least for me that keeps
>> the wake-up interrupts continuously running on omap3 instead of just idle modes.
>>
>> Now on omap4, I've noticed the wake up interrupts are on all the time based on tests
>> with the serial driver.
>
> Oh, and if you're runtime suspending EHCI only, and if the EHCI module has
> wake-up registers, it should be able to wake EHCI from retention on it's own
> without a need for the io chain at all.
>
The problem is that the asynchronous wake up mechanism for USB Host module is broken
in the design so we have to rely on IO daisy chain every time. :(
cheers,
-roger
^ permalink raw reply [flat|nested] 46+ messages in thread
* [PATCH 4/6] pinctrl: single: Add support for wake-up interrupts
2013-10-10 16:00 ` Tony Lindgren
2013-10-10 16:11 ` Linus Walleij
2013-10-10 16:23 ` Tony Lindgren
@ 2013-10-11 8:49 ` Roger Quadros
2013-10-11 13:59 ` Roger Quadros
2 siblings, 1 reply; 46+ messages in thread
From: Roger Quadros @ 2013-10-11 8:49 UTC (permalink / raw)
To: linux-arm-kernel
On 10/10/2013 07:00 PM, Tony Lindgren wrote:
> * Roger Quadros <rogerq@ti.com> [131010 06:32]:
>>
>> I tried testing this with the USB EHCI driver, but I'm not getting wake up interrupts
>> while the system is still running and only the EHCI controller is runtime suspended.
>>
>> It seems we need to somehow call _reconfigure_io_chain() to update the daisy chain
>> whenever the pad wakeup_enable bit is changed.
>
> Sounds like this is on omap3? Have you tried calling pcs_soc->rearm() in the
> pcs_irq_handle() like the comments there suggest? At least for me that keeps
> the wake-up interrupts continuously running on omap3 instead of just idle modes.
Yes it is on OMAP3. I haven't tried with pcs_soc->rearm(). I will give it a try and
let you know.
>
> Now on omap4, I've noticed the wake up interrupts are on all the time based on tests
> with the serial driver.
>
>> I think pcs_irq_set_wake() is where need to control system wakeup behaviour for the irq.
>> This is where we should be able to change WAKEUP_EN bit of the pad
>> to enable/disable system wakeup for that pad and also call _reconfigure_io_chain().
>
> Well the irq_set_wake() should only be needed for suspend and resume. For runtime PM
> the wake-events should be always enabled by default as pointed out by Alan Stern
> a while back.
Right, but we need to update the WAKEUP_EN bit in the pad control register for that
to work, no?. This is something we are not doing in the driver.
>
>> This would mean that we don't really need to set WAKEUP_EN for the pads in the DTS file.
>
> Well for runtime PM, we should also do the automatic handling if configured.
> But how to do that best is still open..
I didn't get this part. I was thinking that irq_set_wake() should map directly to WAKEUP_EN
bit for the pin.
cheers,
-roger
^ permalink raw reply [flat|nested] 46+ messages in thread
* [PATCH 4/6] pinctrl: single: Add support for wake-up interrupts
2013-10-11 8:49 ` Roger Quadros
@ 2013-10-11 13:59 ` Roger Quadros
2013-10-11 15:18 ` Tony Lindgren
0 siblings, 1 reply; 46+ messages in thread
From: Roger Quadros @ 2013-10-11 13:59 UTC (permalink / raw)
To: linux-arm-kernel
On 10/11/2013 11:49 AM, Roger Quadros wrote:
> On 10/10/2013 07:00 PM, Tony Lindgren wrote:
>> * Roger Quadros <rogerq@ti.com> [131010 06:32]:
>>>
>>> I tried testing this with the USB EHCI driver, but I'm not getting wake up interrupts
>>> while the system is still running and only the EHCI controller is runtime suspended.
>>>
>>> It seems we need to somehow call _reconfigure_io_chain() to update the daisy chain
>>> whenever the pad wakeup_enable bit is changed.
>>
>> Sounds like this is on omap3? Have you tried calling pcs_soc->rearm() in the
>> pcs_irq_handle() like the comments there suggest? At least for me that keeps
>> the wake-up interrupts continuously running on omap3 instead of just idle modes.
>
> Yes it is on OMAP3. I haven't tried with pcs_soc->rearm(). I will give it a try and
> let you know.
>>
>> Now on omap4, I've noticed the wake up interrupts are on all the time based on tests
>> with the serial driver.
>>
>>> I think pcs_irq_set_wake() is where need to control system wakeup behaviour for the irq.
>>> This is where we should be able to change WAKEUP_EN bit of the pad
>>> to enable/disable system wakeup for that pad and also call _reconfigure_io_chain().
>>
>> Well the irq_set_wake() should only be needed for suspend and resume. For runtime PM
>> the wake-events should be always enabled by default as pointed out by Alan Stern
>> a while back.
>
> Right, but we need to update the WAKEUP_EN bit in the pad control register for that
> to work, no?. This is something we are not doing in the driver.
OK sorry, just figured out that we are doing it indeed in pcs_irq_set().
Wasn't able to test it yet with USB. But I don't see any issues except that
pcs_soc->rearm() needs to be called from pcs_irq_set() instead of from pcs_irq_unmask().
After that you can add my
Reviewed-by: Roger Quadros <rogerq@ti.com>
cheers,
-roger
^ permalink raw reply [flat|nested] 46+ messages in thread
* [PATCH 4/6] pinctrl: single: Add support for wake-up interrupts
2013-10-11 13:59 ` Roger Quadros
@ 2013-10-11 15:18 ` Tony Lindgren
0 siblings, 0 replies; 46+ messages in thread
From: Tony Lindgren @ 2013-10-11 15:18 UTC (permalink / raw)
To: linux-arm-kernel
* Roger Quadros <rogerq@ti.com> [131011 07:07]:
> On 10/11/2013 11:49 AM, Roger Quadros wrote:
> > On 10/10/2013 07:00 PM, Tony Lindgren wrote:
> >>
> >> Well the irq_set_wake() should only be needed for suspend and resume. For runtime PM
> >> the wake-events should be always enabled by default as pointed out by Alan Stern
> >> a while back.
> >
> > Right, but we need to update the WAKEUP_EN bit in the pad control register for that
> > to work, no?. This is something we are not doing in the driver.
>
> OK sorry, just figured out that we are doing it indeed in pcs_irq_set().
> Wasn't able to test it yet with USB. But I don't see any issues except that
> pcs_soc->rearm() needs to be called from pcs_irq_set() instead of from pcs_irq_unmask().
Hmm that sounds like a different behaviour compared to what I'm seeing
on omap3. Care to send a little fix on top of these patches so I can
test it with my set up too?
It seems that the only difference would be that we're calling rearm()
after both masking and unmasking, which seemed unnecessary to me earlier.
> After that you can add my
>
> Reviewed-by: Roger Quadros <rogerq@ti.com>
Thanks, for testing, sorry I already pushed them out after Kevin
ran his PM tests on them.
Regards,
Tony
^ permalink raw reply [flat|nested] 46+ messages in thread
* [PATCH 5/6] pinctrl: single: Add support for auxdata
2013-10-03 5:42 [PATCH 0/6] add support for omap wake-up interrupts via pinctrl-single, take2 Tony Lindgren
` (3 preceding siblings ...)
2013-10-03 5:42 ` [PATCH 4/6] pinctrl: single: Add support for wake-up interrupts Tony Lindgren
@ 2013-10-03 5:42 ` Tony Lindgren
2013-10-03 5:42 ` [PATCH 6/6] ARM: OMAP: Move DT wake-up event handling over to use pinctrl-single-omap Tony Lindgren
2013-10-10 21:47 ` [PATCH 0/6] add support for omap wake-up interrupts via pinctrl-single, take2 Kevin Hilman
6 siblings, 0 replies; 46+ messages in thread
From: Tony Lindgren @ 2013-10-03 5:42 UTC (permalink / raw)
To: linux-arm-kernel
For omaps, we still have dependencies to the legacy code
for handling the PRM (Power Reset Management) interrupts,
and also for reconfiguring the io wake-up chain after
changes.
Let's pass the PRM interrupt and the rearm functions via
auxdata. Then when at some point we have a proper PRM
driver, we can get the interrupt via device tree and
set up the rearm function as exported function in the
PRM driver.
By using auxdata we can remove a dependency to the
wake-up events for converting omap3 to be device
tree only.
Cc: Peter Ujfalusi <peter.ujfalusi@ti.com>
Cc: Grygorii Strashko <grygorii.strashko@ti.com>
Cc: Prakash Manjunathappa <prakash.pm@ti.com>
Cc: Roger Quadros <rogerq@ti.com>
Cc: Haojian Zhuang <haojian.zhuang@linaro.org>
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: linux-kernel at vger.kernel.org
Signed-off-by: Tony Lindgren <tony@atomide.com>
---
drivers/pinctrl/pinctrl-single.c | 23 +++++++++++++++++++++++
include/linux/platform_data/pinctrl-single.h | 12 ++++++++++++
2 files changed, 35 insertions(+)
create mode 100644 include/linux/platform_data/pinctrl-single.h
diff --git a/drivers/pinctrl/pinctrl-single.c b/drivers/pinctrl/pinctrl-single.c
index b4ff055..e7092e8 100644
--- a/drivers/pinctrl/pinctrl-single.c
+++ b/drivers/pinctrl/pinctrl-single.c
@@ -28,6 +28,8 @@
#include <linux/pinctrl/pinmux.h>
#include <linux/pinctrl/pinconf-generic.h>
+#include <linux/platform_data/pinctrl-single.h>
+
#include "core.h"
#include "pinconf.h"
@@ -159,12 +161,14 @@ struct pcs_name {
* @irq: optional interrupt for the controller
* @irq_enable_mask: optional SoC specific interrupt enable mask
* @irq_status_mask: optional SoC specific interrupt status mask
+ * @rearm: optional SoC specific wake-up rearm function
*/
struct pcs_soc_data {
unsigned flags;
int irq;
unsigned irq_enable_mask;
unsigned irq_status_mask;
+ void (*rearm)(void);
};
/**
@@ -1622,6 +1626,8 @@ static void pcs_irq_unmask(struct irq_data *d)
struct pcs_soc_data *pcs_soc = irq_data_get_irq_chip_data(d);
pcs_irq_set(pcs_soc, d->irq, true);
+ if (pcs_soc->rearm)
+ pcs_soc->rearm();
}
/**
@@ -1672,6 +1678,11 @@ static int pcs_irq_handle(struct pcs_soc_data *pcs_soc)
}
}
+ /*
+ * For debugging on omaps, you may want to call pcs_soc->rearm()
+ * here to see wake-up interrupts during runtime also.
+ */
+
return count;
}
@@ -1838,6 +1849,7 @@ static int pcs_probe(struct platform_device *pdev)
{
struct device_node *np = pdev->dev.of_node;
const struct of_device_id *match;
+ struct pcs_pdata *pdata;
struct resource *res;
struct pcs_device *pcs;
const struct pcs_soc_data *soc;
@@ -1952,6 +1964,17 @@ static int pcs_probe(struct platform_device *pdev)
if (pcs->socdata.irq)
pcs->flags |= PCS_FEAT_IRQ;
+ /* We still need auxdata for some omaps for PRM interrupts */
+ pdata = dev_get_platdata(&pdev->dev);
+ if (pdata) {
+ if (pdata->rearm)
+ pcs->socdata.rearm = pdata->rearm;
+ if (pdata->irq) {
+ pcs->socdata.irq = pdata->irq;
+ pcs->flags |= PCS_FEAT_IRQ;
+ }
+ }
+
if (PCS_HAS_IRQ) {
ret = pcs_irq_init_chained_handler(pcs, np);
if (ret < 0)
diff --git a/include/linux/platform_data/pinctrl-single.h b/include/linux/platform_data/pinctrl-single.h
new file mode 100644
index 0000000..72eacda
--- /dev/null
+++ b/include/linux/platform_data/pinctrl-single.h
@@ -0,0 +1,12 @@
+/**
+ * irq: optional wake-up interrupt
+ * rearm: optional soc specific rearm function
+ *
+ * Note that the irq and rearm setup should come from device
+ * tree except for omap where there are still some dependencies
+ * to the legacy PRM code.
+ */
+struct pcs_pdata {
+ int irq;
+ void (*rearm)(void);
+};
^ permalink raw reply related [flat|nested] 46+ messages in thread* [PATCH 6/6] ARM: OMAP: Move DT wake-up event handling over to use pinctrl-single-omap
2013-10-03 5:42 [PATCH 0/6] add support for omap wake-up interrupts via pinctrl-single, take2 Tony Lindgren
` (4 preceding siblings ...)
2013-10-03 5:42 ` [PATCH 5/6] pinctrl: single: Add support for auxdata Tony Lindgren
@ 2013-10-03 5:42 ` Tony Lindgren
2013-10-10 21:47 ` [PATCH 0/6] add support for omap wake-up interrupts via pinctrl-single, take2 Kevin Hilman
6 siblings, 0 replies; 46+ messages in thread
From: Tony Lindgren @ 2013-10-03 5:42 UTC (permalink / raw)
To: linux-arm-kernel
Now pinctrl-single-omap can handle the wake-up events for us now
as long as the events are configured in the .dts files.
Done in collaboration with Roger Quadros <rogerq@ti.com>.
Cc: Peter Ujfalusi <peter.ujfalusi@ti.com>
Cc: Grygorii Strashko <grygorii.strashko@ti.com>
Cc: Prakash Manjunathappa <prakash.pm@ti.com>
Cc: Roger Quadros <rogerq@ti.com>
Cc: Haojian Zhuang <haojian.zhuang@linaro.org>
Cc: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Roger Quadros <rogerq@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
---
arch/arm/boot/dts/omap3.dtsi | 4 ++++
arch/arm/boot/dts/omap4.dtsi | 4 ++++
arch/arm/mach-omap2/mux.c | 8 ++++++--
arch/arm/mach-omap2/pdata-quirks.c | 18 ++++++++++++++++++
arch/arm/mach-omap2/prm3xxx.h | 8 +++++++-
arch/arm/mach-omap2/prm44xx_54xx.h | 8 +++++++-
arch/arm/mach-omap2/prm_common.c | 11 +++++++++++
7 files changed, 57 insertions(+), 4 deletions(-)
diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index b41bd57..6e928e8 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -107,6 +107,8 @@
reg = <0x48002030 0x05cc>;
#address-cells = <1>;
#size-cells = <0>;
+ #interrupt-cells = <1>;
+ interrupt-controller;
pinctrl-single,register-width = <16>;
pinctrl-single,function-mask = <0xff1f>;
};
@@ -116,6 +118,8 @@
reg = <0x48002a00 0x5c>;
#address-cells = <1>;
#size-cells = <0>;
+ #interrupt-cells = <1>;
+ interrupt-controller;
pinctrl-single,register-width = <16>;
pinctrl-single,function-mask = <0xff1f>;
};
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 22d9f2b..0415d5e 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -114,6 +114,8 @@
reg = <0x4a100040 0x0196>;
#address-cells = <1>;
#size-cells = <0>;
+ #interrupt-cells = <1>;
+ interrupt-controller;
pinctrl-single,register-width = <16>;
pinctrl-single,function-mask = <0x7fff>;
};
@@ -122,6 +124,8 @@
reg = <0x4a31e040 0x0038>;
#address-cells = <1>;
#size-cells = <0>;
+ #interrupt-cells = <1>;
+ interrupt-controller;
pinctrl-single,register-width = <16>;
pinctrl-single,function-mask = <0x7fff>;
};
diff --git a/arch/arm/mach-omap2/mux.c b/arch/arm/mach-omap2/mux.c
index f82cf87..48094b58 100644
--- a/arch/arm/mach-omap2/mux.c
+++ b/arch/arm/mach-omap2/mux.c
@@ -811,6 +811,12 @@ int __init omap_mux_late_init(void)
}
}
+ omap_mux_dbg_init();
+
+ /* see pinctrl-single-omap for the wake-up interrupt handling */
+ if (of_have_populated_dt())
+ return 0;
+
ret = request_irq(omap_prcm_event_to_irq("io"),
omap_hwmod_mux_handle_irq, IRQF_SHARED | IRQF_NO_SUSPEND,
"hwmod_io", omap_mux_late_init);
@@ -818,8 +824,6 @@ int __init omap_mux_late_init(void)
if (ret)
pr_warning("mux: Failed to setup hwmod io irq %d\n", ret);
- omap_mux_dbg_init();
-
return 0;
}
diff --git a/arch/arm/mach-omap2/pdata-quirks.c b/arch/arm/mach-omap2/pdata-quirks.c
index c739631..1f047f4 100644
--- a/arch/arm/mach-omap2/pdata-quirks.c
+++ b/arch/arm/mach-omap2/pdata-quirks.c
@@ -14,6 +14,8 @@
#include <linux/of_platform.h>
#include <linux/wl12xx.h>
+#include <linux/platform_data/pinctrl-single.h>
+
#include "common.h"
#include "common-board-devices.h"
#include "dss-common.h"
@@ -100,7 +102,23 @@ static void __init omap5_uevm_legacy_init(void)
}
#endif
+static struct pcs_pdata pcs_pdata;
+
+void omap_pcs_legacy_init(int irq, void (*rearm)(void))
+{
+ pcs_pdata.irq = irq;
+ pcs_pdata.rearm = rearm;
+}
+
struct of_dev_auxdata omap_auxdata_lookup[] __initdata = {
+#ifdef CONFIG_ARCH_OMAP3
+ OF_DEV_AUXDATA("ti,omap3-padconf", 0x48002030, "48002030.pinmux", &pcs_pdata),
+ OF_DEV_AUXDATA("ti,omap3-padconf", 0x48002a00, "48002a00.pinmux", &pcs_pdata),
+#endif
+#ifdef CONFIG_ARCH_OMAP4
+ OF_DEV_AUXDATA("ti,omap4-padconf", 0x4a100040, "4a100040.pinmux", &pcs_pdata),
+ OF_DEV_AUXDATA("ti,omap4-padconf", 0x4a31e040, "4a31e040.pinmux", &pcs_pdata),
+#endif
{ /* sentinel */ },
};
diff --git a/arch/arm/mach-omap2/prm3xxx.h b/arch/arm/mach-omap2/prm3xxx.h
index 277f717..f8eb833 100644
--- a/arch/arm/mach-omap2/prm3xxx.h
+++ b/arch/arm/mach-omap2/prm3xxx.h
@@ -144,7 +144,13 @@ extern u32 omap3_prm_vcvp_read(u8 offset);
extern void omap3_prm_vcvp_write(u32 val, u8 offset);
extern u32 omap3_prm_vcvp_rmw(u32 mask, u32 bits, u8 offset);
-extern void omap3xxx_prm_reconfigure_io_chain(void);
+#ifdef CONFIG_ARCH_OMAP3
+void omap3xxx_prm_reconfigure_io_chain(void);
+#else
+static inline void omap3xxx_prm_reconfigure_io_chain(void)
+{
+}
+#endif
/* PRM interrupt-related functions */
extern void omap3xxx_prm_read_pending_irqs(unsigned long *events);
diff --git a/arch/arm/mach-omap2/prm44xx_54xx.h b/arch/arm/mach-omap2/prm44xx_54xx.h
index 7cd22ab..a085d9c 100644
--- a/arch/arm/mach-omap2/prm44xx_54xx.h
+++ b/arch/arm/mach-omap2/prm44xx_54xx.h
@@ -42,7 +42,13 @@ extern u32 omap4_prm_vcvp_read(u8 offset);
extern void omap4_prm_vcvp_write(u32 val, u8 offset);
extern u32 omap4_prm_vcvp_rmw(u32 mask, u32 bits, u8 offset);
-extern void omap44xx_prm_reconfigure_io_chain(void);
+#if defined(CONFIG_ARCH_OMAP4) || defined(CONFIG_SOC_OMAP5)
+void omap44xx_prm_reconfigure_io_chain(void);
+#else
+static inline void omap44xx_prm_reconfigure_io_chain(void)
+{
+}
+#endif
/* PRM interrupt-related functions */
extern void omap44xx_prm_read_pending_irqs(unsigned long *events);
diff --git a/arch/arm/mach-omap2/prm_common.c b/arch/arm/mach-omap2/prm_common.c
index 228b850..a2e1174 100644
--- a/arch/arm/mach-omap2/prm_common.c
+++ b/arch/arm/mach-omap2/prm_common.c
@@ -24,6 +24,7 @@
#include <linux/interrupt.h>
#include <linux/slab.h>
+#include "soc.h"
#include "prm2xxx_3xxx.h"
#include "prm2xxx.h"
#include "prm3xxx.h"
@@ -322,6 +323,16 @@ int omap_prcm_register_chain_handler(struct omap_prcm_irq_setup *irq_setup)
prcm_irq_chips[i] = gc;
}
+ if (of_have_populated_dt()) {
+ int irq = omap_prcm_event_to_irq("io");
+ if (cpu_is_omap34xx())
+ omap_pcs_legacy_init(irq,
+ omap3xxx_prm_reconfigure_io_chain);
+ else
+ omap_pcs_legacy_init(irq,
+ omap44xx_prm_reconfigure_io_chain);
+ }
+
return 0;
err:
^ permalink raw reply related [flat|nested] 46+ messages in thread* [PATCH 0/6] add support for omap wake-up interrupts via pinctrl-single, take2
2013-10-03 5:42 [PATCH 0/6] add support for omap wake-up interrupts via pinctrl-single, take2 Tony Lindgren
` (5 preceding siblings ...)
2013-10-03 5:42 ` [PATCH 6/6] ARM: OMAP: Move DT wake-up event handling over to use pinctrl-single-omap Tony Lindgren
@ 2013-10-10 21:47 ` Kevin Hilman
2013-10-10 22:47 ` Tony Lindgren
6 siblings, 1 reply; 46+ messages in thread
From: Kevin Hilman @ 2013-10-10 21:47 UTC (permalink / raw)
To: linux-arm-kernel
Tony Lindgren <tony@atomide.com> writes:
> Here's a respin of the pinctrl-single related patches to use chained
> irq as suggested by Linus W earlier. This series does not try to
> provide any generic automated solution yet, but works by doing a
> request_irq() for the wake-up pin, so it should be flexible enough for
> both manual control and automated solution.
> This series removes the last nasty blocker for making omap3 to be
> device tree only without causing nasty PM regressions.
Indeed, I gave this a spin on several OMAP3 platforms with legacy boot
and ran through a series of retention and off-mode tests for idle and
suspend with both UART and RTC wakeups. No regressions found. So...
Reviewed-by: Kevin Hilman <khilman@linaro.org>
Tested-by: Kevin Hilman <khilman@linaro.org>
on 3530/beagle, 3730/beagle-xM, 3530/Overo, 3730/Overo STORM
Kevin
^ permalink raw reply [flat|nested] 46+ messages in thread* [PATCH 0/6] add support for omap wake-up interrupts via pinctrl-single, take2
2013-10-10 21:47 ` [PATCH 0/6] add support for omap wake-up interrupts via pinctrl-single, take2 Kevin Hilman
@ 2013-10-10 22:47 ` Tony Lindgren
0 siblings, 0 replies; 46+ messages in thread
From: Tony Lindgren @ 2013-10-10 22:47 UTC (permalink / raw)
To: linux-arm-kernel
* Kevin Hilman <khilman@linaro.org> [131010 14:55]:
> Tony Lindgren <tony@atomide.com> writes:
>
> > Here's a respin of the pinctrl-single related patches to use chained
> > irq as suggested by Linus W earlier. This series does not try to
> > provide any generic automated solution yet, but works by doing a
> > request_irq() for the wake-up pin, so it should be flexible enough for
> > both manual control and automated solution.
>
> > This series removes the last nasty blocker for making omap3 to be
> > device tree only without causing nasty PM regressions.
>
> Indeed, I gave this a spin on several OMAP3 platforms with legacy boot
> and ran through a series of retention and off-mode tests for idle and
> suspend with both UART and RTC wakeups. No regressions found. So...
>
> Reviewed-by: Kevin Hilman <khilman@linaro.org>
> Tested-by: Kevin Hilman <khilman@linaro.org>
>
> on 3530/beagle, 3730/beagle-xM, 3530/Overo, 3730/Overo STORM
Thanks for testing, applying these into omap-for-v3.13/quirk
because of the dependencies.
Regards,
Tony
^ permalink raw reply [flat|nested] 46+ messages in thread