[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <5016C006.80008@wwwdotorg.org>
Date: Mon, 30 Jul 2012 11:10:30 -0600
From: Stephen Warren <swarren@...dotorg.org>
To: Mark Brown <broonie@...nsource.wolfsonmicro.com>
CC: Liam Girdwood <lrg@...com>, linux-kernel@...r.kernel.org,
Samuel Ortiz <sameo@...ux.intel.com>,
Stephen Warren <swarren@...dia.com>
Subject: Re: [PATCH 2/3] regmap: implement irq chip suspend/resume operations
On 07/29/2012 03:04 PM, Mark Brown wrote:
> On Fri, Jul 27, 2012 at 01:01:55PM -0600, Stephen Warren wrote:
>
>> When suspending, we set up the wake mask registers as required. Some
>> chips don't have separate wake mask registers, so they set mask_base
>> equal to wake_base. In that case, when resuming, we re-program the
>
> No, they shouldn't be doing that at all - that's at best confused. The
> two registers do different things and if the two ranges are set the same
> then I'd not expect things to work. Supporting that would make the code
> more complex and I'm not sure what benefit we might gain from it.
So this change was re" your comment "This loop we should just port over
into the regmap code." at http://lkml.org/lkml/2012/7/26/466.
I believe the idea is that the chip has an interrupt output from n
sources. Only some of those n sources should trigger a wakeup from
sleep. Hence, the max8907 driver was writing out the "sleep enables" to
the enable registers whenever entering sleep, so that any other IRQ
sources within the chip didn't trigger the chip's interrupt output and
hence exit sleep. If we are to port that code into the regmap-irq core,
it seems to make sense to have enable_base==wake_base, since the same
register truly is being used for both enable/wakeup-enable, just
time-multiplexed.
Or, perhaps the IRQ core already disables all non-wake interrupts for
us, so the driver doesn't have to do this, and we can just drop that
code completely?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists