[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20120729203636.GE4384@opensource.wolfsonmicro.com>
Date: Sun, 29 Jul 2012 21:36:36 +0100
From: Mark Brown <broonie@...nsource.wolfsonmicro.com>
To: Stephen Warren <swarren@...dotorg.org>
Cc: Liam Girdwood <lrg@...com>, linux-kernel@...r.kernel.org,
Samuel Ortiz <sameo@...ux.intel.com>,
Stephen Warren <swarren@...dia.com>
Subject: Re: [PATCH 3/3] regmap: enhance regmap-irq to handle 1 IRQ feeding n
chips
On Fri, Jul 27, 2012 at 01:01:56PM -0600, Stephen Warren wrote:
> From: Stephen Warren <swarren@...dia.com>
>
> Some devices contain a single interrupt output, and multiple separate
> interrupt controllers that all trigger that interrupt output, yet provide
> no top-level interrupt controller/registers to allow determination of
> which child interrupt controller caused the interrupt.
This isn't really anything to do with regmap, it's about implementing
shared IRQ support for threaded interrupts. This is generally useful
and shouldn't be tied to regmap, it's common enough for hardware
designers to want to use wired or interrupts and it's a limitation of
Linux that it can't cope currently.
If are were going to implement it in regmap we shouldn't be faffing
around setting up the virtual interrupts, we should just do the right
thing and call round all the chips without bouncing it through the IRQ
core.
> * Copyright 2011 Wolfson Microelectronics plc
> + * Copyright (c) 2012, NVIDIA CORPORATION. All rights reserved.
All rights reserved? Hrm...
> +static irqreturn_t regmaps_irq_thread(int irq, void *data)
> +{
> + struct regmap_irq_chips_data *d = data;
> + int ret, i;
> +
> + ret = pm_runtime_get_sync(d->dev);
> + if (ret < 0) {
This is conditional in the core regmap runtime PM support, it may be
actively harmful if the device doesn't need it.
--
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