[i2c] [PATCH 2/2] I2C: ISP1301_OMAP: New-style i2c driver updates, part 2
Felipe Balbi
felipebalbi at users.sourceforge.net
Sat Mar 15 13:04:54 CET 2008
Hi,
On Sat, Mar 15, 2008 at 1:59 PM, Jean Delvare <khali at linux-fr.org> wrote:
> Hi Felipe,
>
>
>
> On Fri, 7 Mar 2008 23:00:40 +0200, Felipe Balbi wrote:
> > Hi,
> >
> > On Fri, Mar 7, 2008 at 10:20 PM, David Brownell <david-b at pacbell.net> wrote:
> > > On Tuesday 26 February 2008, Felipe Balbi wrote:
> > > > >
> > > > > Passing irq_flags??? That sounds like nonsense. Please explain ...
> > > >
> > > > request_irq was using different irq flags depending on the board, so
> > > > instead of keeping if (machine_is_*) in the driver just because of irq
> > > > flags we could bring it from a platform_data.
> > >
> > > Just use the resource type flags ... IORESOURCE_IRQ can
> > > be combined with
> >
> > but then isp1301 should become a platform_driver, shouldn't it?
> > I'd need a struct platform_device on the board file and get the device
> > on probe just to get an irq flag?
> >
> > Maybe I'm missing something but I'm understanding something like:
> >
> > --- a/arch/arm/mach-omap1/board-h2.c
> > +++ b/arch/arm/mach-omap1/board-h2.c
> > @@ -140,6 +140,17 @@ static struct platform_device h2_nor_device = {
> > .resource = &h2_nor_resource,
> > };
> >
> > +static struct resource h2_isp1301_resource = {
> > + .flags = IORESOURCE_IRQ | IORESOURCE_IRQ_HIGHEDGE,
> > +};
> > +
> > +static struct platform_device h2_nor_device = {
> > + .name = "isp1301_omap",
> > + .id = 0,
> > + .num_resources = 1,
> > + .resource = &h2_isp1301_resource,
> > +};
> > +
> > static struct mtd_partition h2_nand_partitions[] = {
> > #if 0
> > /* REVISIT: enable these partitions if you make NAND BOOT
> > diff --git a/drivers/i2c/chips/isp1301_omap.c b/drivers/i2c/chips/isp1301_omap.c
> > index 4bb931c..d0a5825 100644
> > --- a/drivers/i2c/chips/isp1301_omap.c
> > +++ b/drivers/i2c/chips/isp1301_omap.c
> > @@ -1453,6 +1453,27 @@ isp1301_start_hnp(struct otg_transceiver *dev)
> >
> > /*-------------------------------------------------------------------------*/
> >
> > +struct platform_driver isp1301_plat_driver = {
> > + .driver = {
> > + .name = DRIVER_NAME,
> > + .bus = &platform_bus_type,
> > + .owner = THIS_MODULE,
> > + },
> > +};
> > +
> > +static int __init isp1301_plat_probe(struct platform_device *pdev)
> > +{
> > + struct resource *resource;
> > +
> > + resource = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
> > + if (!resource)
> > + return -ENODEV;
> > +
> > + the_transceiver->irq_type = resource->flags;
> > +}
> > +
> > +/*-------------------------------------------------------------------------*/
> > +
> > /* no error returns, they'd just make bus scanning stop */
> > static int __init isp1301_probe(struct i2c_client *client)
> > {
> >
> > (of course the code above doesn't work, it's just to clear my mind :-p)
> >
> > Anyways, wouldn't be easier to put a platform_data that can ship
> > withing struct i2c_board_info?
>
> The above looks all wrong to me. The ISP1301 is an I²C device, it gets
> an i2c driver, not a platform driver.
That's what I was trying to say.
> If you need to pass any extra parameter from the platform code to the
> isp1301 driver, you must define a custom structure and pass it as
> i2c_board_info->platform_data. In your case, it would look like:
>
> struct isp1301_platform_data {
> int irq_type;
> }
Yes, I was doing exactly this.
> David, please correct me if I'm wrong.
>
> 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.
Agreed here, the code will also look cleaner if we:
request_irq(client->irq, irq_handler, client->irq_flags,
CLIENT_DRIVER_NAME, client);
--
Best Regards,
Felipe Balbi
felipebalbi at users.sourceforge.net
More information about the i2c
mailing list