On Saturday 29 November 2008, Hans Verkuil wrote:
> > > +And this to go from an i2c_client to a v4l2_subdev struct:
> > > +
> > > + struct v4l2_subdev *sd = i2c_get_clientdata(client);
> > > +
> > > +Finally you need to make a command function to make
> > > +driver->command() call the right subdev_ops functions:
> > > +
> > > +static int
> > > +subdev_command(struct i2c_client *client, unsigned cmd, void *arg)
> > > +{
> > > + return v4l2_subdev_command(i2c_get_clientdata(client), cmd, arg);
> > > +}
> > > +
> > > +If driver->command is never used then you can leave this out.
> > > +Eventually the driver->command usage should be removed from v4l.
> >
> > Should it then be added to the list of features scheduled for removal?
>
> No, driver->command is part of the i2c subsystem and we are not the only
> users, so it can't be scheduled for removal.
ISTR that the only use of the i2c_driver.command() mechanism
is for video/DVB driver support. It's kind of an ugly wart,
and it'd be good to see such ioctl-ish interfaces vanish.
This came up a while back as part of a "how can we clean up
the I2C stack" discussion. So it would be nice if V4L2 wasn't
effectively adding new reasons (and advice) to use this.
- Dave
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
