diff mbox

passing two interrupts two an I2C driver

Message ID 1377163408.10707.29.camel@hornet
State Not Applicable
Headers show

Commit Message

Pawel Moll Aug. 22, 2013, 9:23 a.m. UTC 
On Wed, 2013-08-21 at 18:54 +0100, Mark Brown wrote:
> On Wed, Aug 21, 2013 at 01:37:04PM +0100, Pawel Moll wrote:
> 
> > So let me ask such question... If Device Tree didn't exist, how would
> > you make drive such device? I guess it would require some custom code,
> 
> It's always done using platform data, same for SPI - if we update one we
> should probably update both.

If the platform data used to carry the (custom) irq data, the DT-powered
driver could interrogate the DT on is own, couldn't it? Of course there
should be some helper available, maybe something of that sort? (warning,
untested)

8<---------------------
8<---------------------

Pawel


--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Comments

Mark Brown Aug. 22, 2013, 11:26 a.m. UTC | #1 
On Thu, Aug 22, 2013 at 10:23:28AM +0100, Pawel Moll wrote:

> If the platform data used to carry the (custom) irq data, the DT-powered
> driver could interrogate the DT on is own, couldn't it? Of course there
> should be some helper available, maybe something of that sort? (warning,
> untested)

Yes, that's probably the most straightforward thing - we'd need to
either have the bindings specify which interrupt must be first for
reading i2c->irq or just have the drivers always do a name based lookup
if there's more than one interrupt.
Pawel Moll Aug. 22, 2013, 11:44 a.m. UTC | #2 
On Thu, 2013-08-22 at 12:26 +0100, Mark Brown wrote:
> On Thu, Aug 22, 2013 at 10:23:28AM +0100, Pawel Moll wrote:
> 
> > If the platform data used to carry the (custom) irq data, the DT-powered
> > driver could interrogate the DT on is own, couldn't it? Of course there
> > should be some helper available, maybe something of that sort? (warning,
> > untested)
> 
> Yes, that's probably the most straightforward thing - we'd need to
> either have the bindings specify which interrupt must be first for
> reading i2c->irq or just have the drivers always do a name based lookup
> if there's more than one interrupt.

... or make sure that of_i2c_register_devices() does *not* set i2c->irq
(or rather: set it to 0) when there is more than one interrupt in the
tree...

Paweł


--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Mark Brown Aug. 22, 2013, 1:19 p.m. UTC | #3 
On Thu, Aug 22, 2013 at 12:44:04PM +0100, Pawel Moll wrote:
> On Thu, 2013-08-22 at 12:26 +0100, Mark Brown wrote:

> > Yes, that's probably the most straightforward thing - we'd need to
> > either have the bindings specify which interrupt must be first for
> > reading i2c->irq or just have the drivers always do a name based lookup
> > if there's more than one interrupt.

> ... or make sure that of_i2c_register_devices() does *not* set i2c->irq
> (or rather: set it to 0) when there is more than one interrupt in the
> tree...

Yes, that'd be a really good idea if the drivers are always getting the
interrupts by name, provides a backup.
diff mbox

Patch

diff --git a/drivers/of/irq.c b/drivers/of/irq.c
index 1264923..d2a02dd 100644
--- a/drivers/of/irq.c
+++ b/drivers/of/irq.c
@@ -46,6 +46,15 @@  unsigned int irq_of_parse_and_map(struct device_node *dev, int index)
 }
 EXPORT_SYMBOL_GPL(irq_of_parse_and_map);
 
+unsigned int irq_of_parse_and_map_by_name(struct device_node *dev,
+		const char *name)
+{
+	int index = of_property_match_string(dev, "interrupt-names", name);
+
+	return index < 0 ? 0 : irq_of_parse_and_map(dev, index);
+}
+EXPORT_SYMBOL_GPL(irq_of_parse_and_map_by_name);
+
 /**
  * of_irq_find_parent - Given a device node, find its interrupt parent node
  * @child: pointer to device node