[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <200811291146.44371.david-b@pacbell.net>
Date: Sat, 29 Nov 2008 11:46:43 -0800
From: David Brownell <david-b@...bell.net>
To: Hans Verkuil <hverkuil@...all.nl>,
Laurent Pinchart <laurent.pinchart@...net.be>
Cc: video4linux-list@...hat.com, "Trilok Soni" <soni.trilok@...il.com>,
"linux-omap@...r.kernel.org" <linux-omap@...r.kernel.org>,
"davinci-linux-open-source@...ux.davincidsp.com"
<davinci-linux-open-source@...ux.davincidsp.com>,
linux-kernel@...r.kernel.org
Subject: Re: v4l2_device/v4l2_subdev: please review (PATCH 1/3)
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-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists