Re: [PATCH] ARM: OMAP2+: am33xx: Fix the timer fck clock naming convention
On 7/17/2012 10:14 AM, Hiremath, Vaibhav wrote: > On Tue, Jul 17, 2012 at 05:24:39, Paul Walmsley wrote: >> On Mon, 16 Jul 2012, Vaibhav Hiremath wrote: >> >>> With commit ae6df418a21f3a361c5f9b878e32a8aba4e17692 >>> Sub: ARM: OMAP2+: dmtimer: cleanup fclk usage) >>> The Timer functional clock naming convention has changed from >>> gptX_fck => timerXfck, and so as the timer init function >>> in mach-omap2/timer.c. >>> OMAP4 clocktree also has changed accordingly. >>> >>> AM33xx Clock Tree has been merged during rc3-4 timeframe, >>> before above commit got merged, so similar change is required >>> for AM33xx as well (Change the gptX_fck => timerX_fck). >>> >>> Signed-off-by: Vaibhav Hiremath >> >> Thanks, this looks like 3.6-rc material, right? >> >> > > Yes, that's correct. > Tony/Paul, Ping !!! Thanks, Vaibhav > Thanks, > Vaibhav > > -- > To unsubscribe from this list: send the line "unsubscribe linux-omap" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 02/23] OMAPDSS: outputs: Create and initialize output instances
On Mon, 2012-08-27 at 11:49 +0530, Archit Taneja wrote: > On Friday 24 August 2012 06:44 PM, Tomi Valkeinen wrote: > > On Tue, 2012-08-21 at 11:28 +0530, Archit Taneja wrote: > >> Create output instances by having an init function in the probes of the > >> platform > >> device drivers for different interfaces. Create a small function for each > >> interface to initialize the output entity's fields type and id. > >> > >> In the probe of each interface driver, the output entities are created > >> before > >> the *_probe_pdata() functions intentionally. This is done to ensure that > >> the > >> output entity is prepared before the panels connected to the output are > >> registered. We need the output entities to be ready because OMAPDSS will > >> try > >> to make connections between overlays, managers, outputs and devices during > >> the > >> panel's probe. > > > > You're referring to the recheck_connections stuff? I have a patch that > > moves that to omapfb side. But of course it doesn't hurt to initialize > > the output early. > > I've seen that patch. omapfb would need to take care of connecting > outputs to displays, and managers to outputs. This is added in > recheck_connections done in a patch #9 of the series. > > The question is whether we want some initial connections made between > outputs and displays by DSS, or should that be left completely to > omapfb/omapdrm? Good question. I don't know. Perhaps we should set initial connections there, as the cases where we have multiple displays per output are quite rare. > > We should generally do the initialization in output driver's probe more > > or less so that we first setup everything related to the output driver, > > and after that we register the dssdevs. But I think that's what is > > already done. > > > > So, no complaints =). > > Another thing that comes up with delaying the recheck_connections stuff > is that we can't assume that at the point of panel driver's probe, there > is an output connected to the display. That makes it a bit tricky to > call an output function in the panel's probe, since it isn't connected > to any output at all. An example is when we request for a VC in > taal_probe. Since the panel isn't connected to any output yet, we can't > really call a dsi function to request for the VC. This particular case > can be solved by requesting VCs only when we enable the panel(probably > makes more sense this way), but there might be other situations which > could get tricky to tackle. Right. Well, as you said, we can easily move the stuff from taal's probe to enable. There shouldn't be any problems to that. However, this problem is part of the bigger problem that I haven't been able to solve properly: how to manage the probe/enable stuff for panels. Everything would be simple and easy if we had just one panel per output, and we could just get and configure everything at probe. But we can have multiple panels per output, of which only one can be used at a time... That's why we currently acquire most of the display resources at enable, instead of probe. Tomi signature.asc Description: This is a digitally signed message part
Re: [PATCH 02/23] OMAPDSS: outputs: Create and initialize output instances
On Friday 24 August 2012 06:44 PM, Tomi Valkeinen wrote:
On Tue, 2012-08-21 at 11:28 +0530, Archit Taneja wrote:
Create output instances by having an init function in the probes of the platform
device drivers for different interfaces. Create a small function for each
interface to initialize the output entity's fields type and id.
In the probe of each interface driver, the output entities are created before
the *_probe_pdata() functions intentionally. This is done to ensure that the
output entity is prepared before the panels connected to the output are
registered. We need the output entities to be ready because OMAPDSS will try
to make connections between overlays, managers, outputs and devices during the
panel's probe.
You're referring to the recheck_connections stuff? I have a patch that
moves that to omapfb side. But of course it doesn't hurt to initialize
the output early.
I've seen that patch. omapfb would need to take care of connecting
outputs to displays, and managers to outputs. This is added in
recheck_connections done in a patch #9 of the series.
The question is whether we want some initial connections made between
outputs and displays by DSS, or should that be left completely to
omapfb/omapdrm?
We should generally do the initialization in output driver's probe more
or less so that we first setup everything related to the output driver,
and after that we register the dssdevs. But I think that's what is
already done.
So, no complaints =).
Another thing that comes up with delaying the recheck_connections stuff
is that we can't assume that at the point of panel driver's probe, there
is an output connected to the display. That makes it a bit tricky to
call an output function in the panel's probe, since it isn't connected
to any output at all. An example is when we request for a VC in
taal_probe. Since the panel isn't connected to any output yet, we can't
really call a dsi function to request for the VC. This particular case
can be solved by requesting VCs only when we enable the panel(probably
makes more sense this way), but there might be other situations which
could get tricky to tackle.
Signed-off-by: Archit Taneja
---
drivers/video/omap2/dss/dpi.c | 20
drivers/video/omap2/dss/dsi.c | 26 --
drivers/video/omap2/dss/hdmi.c | 18 ++
drivers/video/omap2/dss/rfbi.c | 19 +++
drivers/video/omap2/dss/sdi.c | 20
drivers/video/omap2/dss/venc.c | 20
6 files changed, 121 insertions(+), 2 deletions(-)
diff --git a/drivers/video/omap2/dss/dpi.c b/drivers/video/omap2/dss/dpi.c
index f260343..4eca2e7 100644
--- a/drivers/video/omap2/dss/dpi.c
+++ b/drivers/video/omap2/dss/dpi.c
@@ -408,10 +408,30 @@ static void __init dpi_probe_pdata(struct platform_device
*pdev)
}
}
+static int __init dpi_init_output(struct platform_device *pdev)
+{
+ struct omap_dss_output *out;
+
+ out = dss_create_output(pdev);
+ if (!out)
+ return -ENOMEM;
+
+ out->id = OMAP_DSS_OUTPUT_DPI;
+ out->type = OMAP_DISPLAY_TYPE_DPI;
+
+ return 0;
+}
+
static int __init omap_dpi_probe(struct platform_device *pdev)
{
+ int r;
+
mutex_init(&dpi.lock);
+ r = dpi_init_output(pdev);
+ if (r)
+ return r;
+
dpi_probe_pdata(pdev);
return 0;
diff --git a/drivers/video/omap2/dss/dsi.c b/drivers/video/omap2/dss/dsi.c
index 659b6cd..22e0873 100644
--- a/drivers/video/omap2/dss/dsi.c
+++ b/drivers/video/omap2/dss/dsi.c
@@ -4903,6 +4903,23 @@ static void __init dsi_probe_pdata(struct
platform_device *dsidev)
}
}
+static int __init dsi_init_output(struct platform_device *dsidev,
+ struct dsi_data *dsi)
+{
+ struct omap_dss_output *out;
+
+ out = dss_create_output(dsidev);
+ if (!out)
+ return -ENOMEM;
+
+ out->id = dsi->module_id == 0 ?
+ OMAP_DSS_OUTPUT_DSI1 : OMAP_DSS_OUTPUT_DSI2;
+
+ out->type = OMAP_DISPLAY_TYPE_DSI;
+
+ return 0;
As I mentioned in the last email, I think this could be something like:
struct omap_dss_output *out = &dsi->output;
out->pdev = dsidev;
out->id = xxx;
out->type = yyy;
dss_register_output(out);
Right, this is much better, will do it this way.
+}
+
/* DSI1 HW IP initialisation */
static int __init omap_dsihw_probe(struct platform_device *dsidev)
{
@@ -4997,10 +5014,14 @@ static int __init omap_dsihw_probe(struct
platform_device *dsidev)
else
dsi->num_lanes_supported = 3;
- dsi_probe_pdata(dsidev);
-
dsi_runtime_put(dsidev);
+ r = dsi_init_output(dsidev, dsi);
+ if (r)
+ goto err_init_output;
+
+ dsi_probe_pdata(dsidev);
+
Why do you change the sequence here? Isn't it enough to just add the
init_output before probe_pdata?
Yes, I think I didn't
[PATCH] ARM: OMAP2+: select PINCTRL in Kconfig
Select PINCTRL in Kconfig under Typical OMAP configuration, this is required to add pinctrl driver to omap2+ family of devices. Signed-off-by: AnilKumar Ch --- arch/arm/mach-omap2/Kconfig |1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig index dd2db02..a164568 100644 --- a/arch/arm/mach-omap2/Kconfig +++ b/arch/arm/mach-omap2/Kconfig @@ -18,6 +18,7 @@ config ARCH_OMAP2PLUS_TYPICAL select TWL4030_CORE if ARCH_OMAP3 || ARCH_OMAP4 select TWL4030_POWER if ARCH_OMAP3 || ARCH_OMAP4 select HIGHMEM + select PINCTRL help Compile a kernel suitable for booting most boards -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v9] can: c_can: Add runtime PM support to Bosch C_CAN/D_CAN controller
Hi Marc,
On Mon, Aug 20, 2012 at 16:50:54, AnilKumar, Chimata wrote:
> Add Runtime PM support to C_CAN/D_CAN controller. The runtime PM
> APIs control clocks for C_CAN/D_CAN IP and prevent access to the
> register of C_CAN/D_CAN IP when clock is turned off.
>
> Signed-off-by: AnilKumar Ch
> ---
> This patch has been tested on AM335X EVM. Due to lack of hardware
> I am not able to test c_can functionality. I appreciate if anyone
> can test c_can functionality with this patch.
>
> This patch is based on "can-next/master"
>
> Changes from v8:
> - corrected the return path sequence in c_can_probe()
>
> Changes from v7:
> - Incorporated Marc's comments on v7
> * changed device pointer to c_can_priv pointer
>
> Changes from v6:
> - Incorporated Marc's comments on v6
> * changed dev pointer to priv
> * removed platform_device.h include from c_can.c
>
> Changes from v5:
> - Incorporated Marc's comments on v5
> * changed runtime pm calls in c_can driver to handle
> the drivers which are not using platform drivers.
> * added device pointer protection in c_can driver if
> not passed from platform/pci driver.
>
> Changes from v4:
> - Incorporated Vaibhav H review comments on v4.
> * Moved pm_runtime put/get_sync calls to appropriate positions.
> - This patch is from "Add DT support to C_CAN/D_CAN controller"
> patch series. Rest of the patches in this series were applied
> so this v5 contains only this patch.
>
> drivers/net/can/c_can/c_can.c | 24 +++-
> drivers/net/can/c_can/c_can.h |1 +
> drivers/net/can/c_can/c_can_platform.c | 11 +--
> 3 files changed, 33 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/net/can/c_can/c_can.c b/drivers/net/can/c_can/c_can.c
> index 4c538e3..966d318 100644
> --- a/drivers/net/can/c_can/c_can.c
> +++ b/drivers/net/can/c_can/c_can.c
> @@ -34,6 +34,7 @@
> #include
> #include
> #include
> +#include
>
> #include
> #include
> @@ -201,6 +202,18 @@ static const struct can_bittiming_const
> c_can_bittiming_const = {
> .brp_inc = 1,
> };
>
> +static inline void c_can_pm_runtime_get_sync(struct c_can_priv *priv)
> +{
> + if (priv->device)
> + pm_runtime_get_sync(priv->device);
> +}
> +
> +static inline void c_can_pm_runtime_put_sync(struct c_can_priv *priv)
> +{
> + if (priv->device)
> + pm_runtime_put_sync(priv->device);
> +}
> +
> static inline int get_tx_next_msg_obj(const struct c_can_priv *priv)
> {
> return (priv->tx_next & C_CAN_NEXT_MSG_OBJ_MASK) +
> @@ -673,11 +686,15 @@ static int c_can_get_berr_counter(const struct
> net_device *dev,
> unsigned int reg_err_counter;
> struct c_can_priv *priv = netdev_priv(dev);
>
> + c_can_pm_runtime_get_sync(priv);
> +
> reg_err_counter = priv->read_reg(priv, C_CAN_ERR_CNT_REG);
> bec->rxerr = (reg_err_counter & ERR_CNT_REC_MASK) >>
> ERR_CNT_REC_SHIFT;
> bec->txerr = reg_err_counter & ERR_CNT_TEC_MASK;
>
> + c_can_pm_runtime_put_sync(priv);
> +
> return 0;
> }
>
> @@ -1053,11 +1070,13 @@ static int c_can_open(struct net_device *dev)
> int err;
> struct c_can_priv *priv = netdev_priv(dev);
>
> + c_can_pm_runtime_get_sync(priv);
> +
> /* open the can device */
> err = open_candev(dev);
> if (err) {
> netdev_err(dev, "failed to open can device\n");
> - return err;
> + goto exit_open_fail;
> }
>
> /* register interrupt handler */
> @@ -1079,6 +1098,8 @@ static int c_can_open(struct net_device *dev)
>
> exit_irq_fail:
> close_candev(dev);
> +exit_open_fail:
> + c_can_pm_runtime_put_sync(priv);
> return err;
> }
>
> @@ -1091,6 +1112,7 @@ static int c_can_close(struct net_device *dev)
> c_can_stop(dev);
> free_irq(dev->irq, dev);
> close_candev(dev);
> + c_can_pm_runtime_put_sync(priv);
>
> return 0;
> }
> diff --git a/drivers/net/can/c_can/c_can.h b/drivers/net/can/c_can/c_can.h
> index 4e56baa..1437a6d 100644
> --- a/drivers/net/can/c_can/c_can.h
> +++ b/drivers/net/can/c_can/c_can.h
> @@ -153,6 +153,7 @@ struct c_can_priv {
> struct can_priv can;/* must be the first member */
> struct napi_struct napi;
> struct net_device *dev;
> + struct device *device;
> int tx_object;
> int current_status;
> int last_status;
> diff --git a/drivers/net/can/c_can/c_can_platform.c
> b/drivers/net/can/c_can/c_can_platform.c
> index d0a66cf..90801c4 100644
> --- a/drivers/net/can/c_can/c_can_platform.c
> +++ b/drivers/net/can/c_can/c_can_platform.c
> @@ -32,6 +32,7 @@
> #include
> #include
> #include
> +#include
>
> #include
>
> @@ -177,8 +178,11 @@ static int __devinit c_can_plat_probe(struct
> platform_device *pdev)
> goto e
Re: [PATCH] OMAP GPIO - don't wake from suspend unless requested.
On Sun, Aug 26, 2012 at 3:53 PM, NeilBrown wrote:
>
> On Sun, 26 Aug 2012 09:47:50 +0530 "Shilimkar, Santosh"
> wrote:
>
> > + Jon,
> >
> > On Sat, Aug 25, 2012 at 5:14 PM, NeilBrown wrote:
> > >
> > >
> > >
> > > Current kernel will wake from suspend on an event on any active
> > > GPIO even if enable_irq_wake() wasn't called.
> > >
> > > There are two reasons that the hardware wake-enable bit should be set:
> > >
> > > 1/ while non-suspended the CPU might go into a deep sleep (off_mode)
> > > in which the wake-enable bit is needed for an interrupt to be
> > > recognised.
> > > 2/ while suspended the GPIO interrupt should wake from suspend if and
> > >only if irq_wake as been enabled.
> > >
> > > The code currently doesn't keep these two reasons separate so they get
> > > confused and sometimes the wakeup flags is set incorrectly.
> > >
> > > This patch reverts:
> > > commit 9c4ed9e6c01e7a8bd9079da8267e1f03cb4761fc
> > > gpio/omap: remove suspend/resume callbacks
> > > and
> > > commit 0aa2727399c0b78225021413022c164cb99fbc5e
> > > gpio/omap: remove suspend_wakeup field from struct gpio_bank
> > >
> > > and makes some minor changes so that we have separate flags for "GPIO
> > > should wake from deep idle" and "GPIO should wake from suspend".
> > >
> > > With this patch, the GPIO from my touch screen doesn't wake my device
> > > any more, which is what I want.
> > >
> > > Cc: Kevin Hilman
> > > Cc: Tony Lindgren
> > > Cc: Santosh Shilimkar
> > > Cc: Cousson, Benoit
> > > Cc: Grant Likely
> > > Cc: Tarun Kanti DebBarma
> > > Cc: Felipe Balbi
> > > Cc: Govindraj.R
> > >
> > > Signed-off-by: NeilBrown
> > >
> > The patch doesn't seems to be correct. At least the 2/ gets
> > fixed with a proper IRQCHIP flag. Can you try the patch at
> > end of the email and see if it helps ? Am attaching it in case
> > mailer damages it.
> >
> > Regards
> > Santosh
> >
> > >From b8a38fc75e046f6462610e26c47c620cad850c24 Mon Sep 17 00:00:00 2001
> > From: Santosh Shilimkar
> > Date: Sun, 26 Aug 2012 09:39:51 +0530
> > Subject: [PATCH] gpio: omap: Set IRQCHIP_MASK_ON_SUSPEND to mask all
> > non-wakeup gpio wakeups.
> >
> > Set the irq chip flag IRQCHIP_MASK_ON_SUSPEND to cause the irq pm code
> > to mask all non-wake gpios in suspend, which will ensure the wakeup
> > enable
> > bit is not set on non-wake gpios.
> >
> > Signed-off-by: Santosh Shilimkar
> > ---
> > drivers/gpio/gpio-omap.c |1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
> > index e6efd77..50b4c18 100644
> > --- a/drivers/gpio/gpio-omap.c
> > +++ b/drivers/gpio/gpio-omap.c
> > @@ -779,6 +779,7 @@ static struct irq_chip gpio_irq_chip = {
> > .irq_unmask = gpio_unmask_irq,
> > .irq_set_type = gpio_irq_type,
> > .irq_set_wake = gpio_wake_enable,
> > + .flags = IRQCHIP_MASK_ON_SUSPEND;
> > };
> >
> >
> > /*-*/
>
>
> No obvious damage, unless the mailer is responsible or the ';' at the end
> of
> the line, rather than ',' :-)
>
:-) That was typo.
> The approach makes sense, but does actually work. Should be fixable
> though.
>
> When I try this I get:
>
>
>
> [ 158.114440] Checking wakeup interrupts
> [ 158.118408] Unhandled fault: external abort on non-linefetch (0x1028)
> at 0xfb054040
> [ 158.126403] Internal error: : 1028 [#1] PREEMPT ARM
> [ 158.131500] Modules linked in: ipv6 g_ether hso libertas_sdio libertas
> cfg80211
> [ 158.139190] CPU: 0Not tainted (3.5.0-gta04-debug+ #2)
> [ 158.144927] PC is at _set_gpio_triggering+0x38/0x258
> [ 158.150115] LR is at gpio_mask_irq+0xac/0xc0
> [ 158.154602] pc : []lr : []psr: 6193
> [ 158.154602] sp : db521e90 ip : 0011 fp : beeecc2c
> [ 158.166595] r10: c05c8ebc r9 : daa5a858 r8 : 0003
> [ 158.172027] r7 : a193 r6 : r5 : fb054000 r4 : ded44e18
> [ 158.178863] r3 : 0001 r2 : r1 : ded30340 r0 : 0040
> [ 158.185668] Flags: nZCv IRQs off FIQs on Mode SVC_32 ISA ARM
> Segment use
>
> so it looks like runtime PM has turned off the iclk to the GPIO module so
> that
> when we try to tell it to change settings, it is no longer listening to
> us.
>From the crash logs it appears like that.
> The "Checking wakeup interrupts" function happens very late in the suspend
> cycle, after all the suspend_late and suspend_noirq functions have run.
> Maybe it needs to be moved earlier...
>
No it shouldn't be moved and it is that point for lot many good
reasons. Ofcourse
this omap gpio driver crash needs to be addressed. Need to think bit
more on this
issue.
Regards
Santosh
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] OMAP GPIO - don't wake from suspend unless requested.
On Sun, 26 Aug 2012 09:47:50 +0530 "Shilimkar, Santosh"
wrote:
> + Jon,
>
> On Sat, Aug 25, 2012 at 5:14 PM, NeilBrown wrote:
> >
> >
> >
> > Current kernel will wake from suspend on an event on any active
> > GPIO even if enable_irq_wake() wasn't called.
> >
> > There are two reasons that the hardware wake-enable bit should be set:
> >
> > 1/ while non-suspended the CPU might go into a deep sleep (off_mode)
> > in which the wake-enable bit is needed for an interrupt to be
> > recognised.
> > 2/ while suspended the GPIO interrupt should wake from suspend if and
> >only if irq_wake as been enabled.
> >
> > The code currently doesn't keep these two reasons separate so they get
> > confused and sometimes the wakeup flags is set incorrectly.
> >
> > This patch reverts:
> > commit 9c4ed9e6c01e7a8bd9079da8267e1f03cb4761fc
> > gpio/omap: remove suspend/resume callbacks
> > and
> > commit 0aa2727399c0b78225021413022c164cb99fbc5e
> > gpio/omap: remove suspend_wakeup field from struct gpio_bank
> >
> > and makes some minor changes so that we have separate flags for "GPIO
> > should wake from deep idle" and "GPIO should wake from suspend".
> >
> > With this patch, the GPIO from my touch screen doesn't wake my device
> > any more, which is what I want.
> >
> > Cc: Kevin Hilman
> > Cc: Tony Lindgren
> > Cc: Santosh Shilimkar
> > Cc: Cousson, Benoit
> > Cc: Grant Likely
> > Cc: Tarun Kanti DebBarma
> > Cc: Felipe Balbi
> > Cc: Govindraj.R
> >
> > Signed-off-by: NeilBrown
> >
> The patch doesn't seems to be correct. At least the 2/ gets
> fixed with a proper IRQCHIP flag. Can you try the patch at
> end of the email and see if it helps ? Am attaching it in case
> mailer damages it.
>
> Regards
> Santosh
>
> >From b8a38fc75e046f6462610e26c47c620cad850c24 Mon Sep 17 00:00:00 2001
> From: Santosh Shilimkar
> Date: Sun, 26 Aug 2012 09:39:51 +0530
> Subject: [PATCH] gpio: omap: Set IRQCHIP_MASK_ON_SUSPEND to mask all
> non-wakeup gpio wakeups.
>
> Set the irq chip flag IRQCHIP_MASK_ON_SUSPEND to cause the irq pm code
> to mask all non-wake gpios in suspend, which will ensure the wakeup enable
> bit is not set on non-wake gpios.
>
> Signed-off-by: Santosh Shilimkar
> ---
> drivers/gpio/gpio-omap.c |1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
> index e6efd77..50b4c18 100644
> --- a/drivers/gpio/gpio-omap.c
> +++ b/drivers/gpio/gpio-omap.c
> @@ -779,6 +779,7 @@ static struct irq_chip gpio_irq_chip = {
> .irq_unmask = gpio_unmask_irq,
> .irq_set_type = gpio_irq_type,
> .irq_set_wake = gpio_wake_enable,
> + .flags = IRQCHIP_MASK_ON_SUSPEND;
> };
>
> /*-*/
No obvious damage, unless the mailer is responsible or the ';' at the end of
the line, rather than ',' :-)
The approach makes sense, but does actually work. Should be fixable though.
When I try this I get:
[ 158.114440] Checking wakeup interrupts
[ 158.118408] Unhandled fault: external abort on non-linefetch (0x1028) at
0xfb054040
[ 158.126403] Internal error: : 1028 [#1] PREEMPT ARM
[ 158.131500] Modules linked in: ipv6 g_ether hso libertas_sdio libertas
cfg80211
[ 158.139190] CPU: 0Not tainted (3.5.0-gta04-debug+ #2)
[ 158.144927] PC is at _set_gpio_triggering+0x38/0x258
[ 158.150115] LR is at gpio_mask_irq+0xac/0xc0
[ 158.154602] pc : []lr : []psr: 6193
[ 158.154602] sp : db521e90 ip : 0011 fp : beeecc2c
[ 158.166595] r10: c05c8ebc r9 : daa5a858 r8 : 0003
[ 158.172027] r7 : a193 r6 : r5 : fb054000 r4 : ded44e18
[ 158.178863] r3 : 0001 r2 : r1 : ded30340 r0 : 0040
[ 158.185668] Flags: nZCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment use
so it looks like runtime PM has turned off the iclk to the GPIO module so that
when we try to tell it to change settings, it is no longer listening to us.
The "Checking wakeup interrupts" function happens very late in the suspend
cycle, after all the suspend_late and suspend_noirq functions have run.
Maybe it needs to be moved earlier...
Thanks,
NeilBrown
signature.asc
Description: PGP signature
