Re: [PATCH 2/2] I2C: ISP1301_OMAP: New-style i2c driver updates, part 2

[David Brownell <david-b-yBeKhBN/0LDR7s880joybQ@public.gmane.org>]

On Saturday 15 March 2008, Jean Delvare wrote:
> The above looks all wrong to me. The ISP1301 is an I²C device, it gets
> an i2c driver, not a platform driver.

Right; blame that on me, for a moment I forgot and so I
mentioned the use of the IORESOURCE_IRQ_* flags, which work
on busses using resources -- like "platform" and "pnp").
Not helpful here.


> That being said, if many drivers need an irq_type field in addition to
> the irq number, we might consider adding an irq_type field to struct
> i2c_board_info and struct i2c_client directly. It probably doesn't make
> much sense to have irq and irq_type take different routes if they are
> most often needed together.

Actually ... why not just require the board-specific setup
code to set the right trigger mode?  Use set_irq_type().

That's what x86 does, and it works fine.  Drivers don't need
to worry about trigger modes ("irq_type") at all, since the
board setup code (on PCs: ACPI or BIOS) just stuffs the same
registers that set_irq_type() would stuff.  Drivers can just:

   status = request_irq(irq, handler, 0, "name", data);

Platforms already do the pinmux setup, making sure that the
relevant pin is set up as an external interrupt source or
GPIO input as appropriate.  They can just as well do the rest.

- Dave





_______________________________________________
i2c mailing list
i2c-GZX6beZjE8VD60Wz+7aTrA@public.gmane.org
http://lists.lm-sensors.org/mailman/listinfo/i2c