Re: passing two interrupts two an I2C driver

Re: passing two interrupts two an I2C driver

[Pawel Moll]

[resending, this time really copying Wolfram and linux-i2c...]

On Wed, 2013-08-21 at 12:53 +0100, Jacek Anaszewski wrote:
>  From what I've figured out in order to obtain the interrupt id
> by name the function
> 
> platform_get_irq_by_name(struct platform_device *dev, const char *name)
> 
> has to be exploited. Unfortunately required platform_device structure
> is not available in the struct i2c_client

Well, platform devices belong to platform bus, nothing to do with I2C.
Platform devices are associated with an array of named resources and the
code creating such devices from the DT nodes (of_device_alloc()) do the
necessary magic.

>  that is passed to the
> probe function of an i2c driver. Is there some different way to parse
> the interrupt-names property from the I2C driver?

Interesting. Very interesting indeed. It seems (at least at the first
sight) that I2C framework assumes that only one interrupt can be
generated by a I2C device:

struct i2c_client {                                                                         
[...]
        int irq;                        /* irq issued by device         */                  
[...]
};                                                                               

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,
as struct i2c_board_info has single int irq as well... If this is the
case, you could parse the irq properties in a similar way as done in
of_irq_to_resource() in drivers/of/irq.c. Doesn't like the optimal
solution, though...

I've copied Wolfram and the I2C mailing list in hope of them shedding
some light at the matter.

Pawel

Re: passing two interrupts two an I2C driver

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 309 bytes --]

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.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: passing two interrupts two an I2C driver

[Pawel Moll]

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<---------------------
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
8<---------------------

Pawel

Re: passing two interrupts two an I2C driver

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 540 bytes --]

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.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: passing two interrupts two an I2C driver

[Pawel Moll]

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ł

Re: passing two interrupts two an I2C driver

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 643 bytes --]

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.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]