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

[Hans Verkuil <hverkuil@xs4all.nl>]

On Saturday 29 November 2008 20:46:43 David Brownell wrote:
> 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.

If v4l is indeed the only user, then once all i2c drivers are converted 
to this new sub device API, then command can indeed go away.

Would be nice, but it will probably take a few kernel cycles before we 
are there. It's a lot of work, but very worthwhile in my opinion.

Regards,

	Hans

-- 
Hans Verkuil - video4linux developer - sponsored by TANDBERG