Re: v4l2_device/v4l2_subdev: please review (PATCH 1/3)

[David Brownell <david-b@pacbell.net>]

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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html