[GIT PULL FOR 3.1] Bitmask controls, flash API and adp1653 driver
Hi Mauro, This pull request adds the bitmask controls, flash API and the adp1653 driver. Laurent noticed an issue with the previous pull request and I've fixed that. Changes since the second pull request: - Properly call validate_new_int() from validate_new() for bitmask controls. Changes since the first pull request to the second one: - Added a patch to document the V4L2 control endianness. It's on the top. - Rebased the patches. I haven't tested vivi, though. - The adp1653 uses dev_pm_ops instead of i2c ops for suspend/resume. Changes since the last patchset since the first pull request: - Adp1653 flash faults control is volatile. Fix this. - Flash interface marked as experimental. - Moved the DocBook documentation to a new location. - The target version is 3.1, not 2.6.41. The following changes since commit df6aabbeb2b8799d97f3886fc994c318bc6a6843: [media] v4l2-ctrls.c: add support for V4L2_EVENT_SUB_FL_ALLOW_FEEDBACK (2011-07-01 20:54:51 -0300) are available in the git repository at: ssh://linuxtv.org/git/sailus/media_tree.git media-for-3.1-flash-4 Hans Verkuil (3): v4l2-ctrls: add new bitmask control type. vivi: add bitmask test control. DocBook: document V4L2_CTRL_TYPE_BITMASK. Sakari Ailus (4): v4l: Add a class and a set of controls for flash devices. v4l: Add flash control documentation adp1653: Add driver for LED flash controller v4l: Document V4L2 control endianness as machine endianness. Documentation/DocBook/media/v4l/compat.xml | 11 + Documentation/DocBook/media/v4l/controls.xml | 291 Documentation/DocBook/media/v4l/v4l2.xml |6 +- .../DocBook/media/v4l/vidioc-g-ext-ctrls.xml |7 + .../DocBook/media/v4l/vidioc-queryctrl.xml | 12 +- drivers/media/video/Kconfig|9 + drivers/media/video/Makefile |1 + drivers/media/video/adp1653.c | 491 drivers/media/video/v4l2-common.c |3 + drivers/media/video/v4l2-ctrls.c | 63 +++- drivers/media/video/vivi.c | 18 +- include/linux/videodev2.h | 37 ++ include/media/adp1653.h| 126 + 13 files changed, 1068 insertions(+), 7 deletions(-) create mode 100644 drivers/media/video/adp1653.c create mode 100644 include/media/adp1653.h -- Sakari Ailus sakari.ai...@iki.fi -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PULL FOR 3.1] Bitmask controls, flash API and adp1653 driver
Hi Mauro, This pull request adds the bitmask controls, flash API and the adp1653 driver. Changes since the first pull request: - Added a patch to document the V4L2 control endianness. It's on the top. - Rebased the patches. I haven't tested vivi, though. - The adp1653 uses dev_pm_ops instead of i2c ops for suspend/resume. Changes since the last patchset since the first pull request: - Adp1653 flash faults control is volatile. Fix this. - Flash interface marked as experimental. - Moved the DocBook documentation to a new location. - The target version is 3.1, not 2.6.41. The following changes since commit df6aabbeb2b8799d97f3886fc994c318bc6a6843: [media] v4l2-ctrls.c: add support for V4L2_EVENT_SUB_FL_ALLOW_FEEDBACK (2011-07-01 20:54:51 -0300) are available in the git repository at: ssh://linuxtv.org/git/sailus/media_tree.git media-for-3.1-flash-3 Hans Verkuil (3): v4l2-ctrls: add new bitmask control type. vivi: add bitmask test control. DocBook: document V4L2_CTRL_TYPE_BITMASK. Sakari Ailus (4): v4l: Add a class and a set of controls for flash devices. v4l: Add flash control documentation adp1653: Add driver for LED flash controller v4l: Document V4L2 control endianness as machine endianness. Documentation/DocBook/media/v4l/compat.xml | 11 + Documentation/DocBook/media/v4l/controls.xml | 291 Documentation/DocBook/media/v4l/v4l2.xml |6 +- .../DocBook/media/v4l/vidioc-g-ext-ctrls.xml |7 + .../DocBook/media/v4l/vidioc-queryctrl.xml | 12 +- drivers/media/video/Kconfig|9 + drivers/media/video/Makefile |1 + drivers/media/video/adp1653.c | 491 drivers/media/video/v4l2-common.c |3 + drivers/media/video/v4l2-ctrls.c | 62 +++- drivers/media/video/vivi.c | 18 +- include/linux/videodev2.h | 37 ++ include/media/adp1653.h| 126 + 13 files changed, 1067 insertions(+), 7 deletions(-) create mode 100644 drivers/media/video/adp1653.c create mode 100644 include/media/adp1653.h -- Sakari Ailus sakari.ai...@iki.fi -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL FOR 3.1] Bitmask controls, flash API and adp1653 driver
Mauro Carvalho Chehab wrote: Em 01-07-2011 08:15, Sakari Ailus escreveu: On Fri, Jul 01, 2011 at 09:57:39AM +0200, Hans Verkuil wrote: On Friday, July 01, 2011 03:27:10 Mauro Carvalho Chehab wrote: Em 10-06-2011 06:27, Sakari Ailus escreveu: Hi Mauro, This pull request adds the bitmask controls, flash API and the adp1653 driver. What has changed since the patches is: - Adp1653 flash faults control is volatile. Fix this. - Flash interface marked as experimental. - Moved the DocBook documentation to a new location. - The target version is 3.1, not 2.6.41. The following changes since commit 75125b9d44456e0cf2d1fbb72ae33c13415299d1: [media] DocBook: Don't be noisy at make cleanmediadocs (2011-06-09 16:40:58 -0300) are available in the git repository at: ssh://linuxtv.org/git/sailus/media_tree.git media-for-3.1 Hans Verkuil (3): v4l2-ctrls: add new bitmask control type. vivi: add bitmask test control. DocBook: document V4L2_CTRL_TYPE_BITMASK. I'm sure I've already mentioned, but I think it was at the Hans pull request: the specs don't mention what endiannes is needed for the bitmask controls: machine endianess, little endian or big endian. IMO, we should stick with either LE or BE. Sorry Sakari, I should have fixed that. But since the patch was going through your repository I forgot about it. Anyway, it should be machine endianess. You have to be able to do (value bit_define). The bit_defines for each bitmask control should be part of the control's definition in videodev2.h. It makes no sense to require LE or BE. We don't do that for other control types, so why should bitmask be any different? Can you add this clarification to DocBook? Thinking about this some more, if we're to say something about the endianness we should specify it for all controls, not just bitmasks. I really wonder if need this at all: why would you think the endianness in a bitmask would be some other than machine endianness, be it a V4L2 control or a flags field in, say, struct v4l2_buffer? It would make sense to document it if it differs from the norm, so in my opinion such statement would be redundant. Because someone might have the bright idea of exposing a hardware register via V4L2_CTRL_TYPE_BITMASK directly without reminding about the endiannes, and do the wrong thing. The same could be done to an integer control as well, the bitmask isn't special in that sense. Just my opinion. The spec says When for example a hardware register accepts values 0-511 and the driver reports 0-65535, step should be 128. on step field in struct v4l2_queryctrl. This suggests that registers may be exposed to user space as integer controls. So endianness issues may exist on other types of controls as well if the programmer didn't remember that other endian than his existed. There's not much problem on being redundant at the specs, but not specifying it means that different implementations will still be valid. Btw, if you take a look at the descriptions for RGB format at the spec, you'll see that endiannes problems already happened in the past: the specs had to explicitly allow both endiannes for a few RGB formats due to that. I'm ok if we standardize that it should be the machine endiannes, but we should be explicit on that. I'll add a few words on this, but should it be added to bitmask controls documentation or controls in general? Regards, -- Sakari Ailus sakari.ai...@iki.fi -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL FOR 3.1] Bitmask controls, flash API and adp1653 driver
Em 02-07-2011 15:03, Sakari Ailus escreveu: Mauro Carvalho Chehab wrote: Em 01-07-2011 08:15, Sakari Ailus escreveu: On Fri, Jul 01, 2011 at 09:57:39AM +0200, Hans Verkuil wrote: On Friday, July 01, 2011 03:27:10 Mauro Carvalho Chehab wrote: Em 10-06-2011 06:27, Sakari Ailus escreveu: Hi Mauro, This pull request adds the bitmask controls, flash API and the adp1653 driver. What has changed since the patches is: - Adp1653 flash faults control is volatile. Fix this. - Flash interface marked as experimental. - Moved the DocBook documentation to a new location. - The target version is 3.1, not 2.6.41. The following changes since commit 75125b9d44456e0cf2d1fbb72ae33c13415299d1: [media] DocBook: Don't be noisy at make cleanmediadocs (2011-06-09 16:40:58 -0300) are available in the git repository at: ssh://linuxtv.org/git/sailus/media_tree.git media-for-3.1 Hans Verkuil (3): v4l2-ctrls: add new bitmask control type. vivi: add bitmask test control. DocBook: document V4L2_CTRL_TYPE_BITMASK. I'm sure I've already mentioned, but I think it was at the Hans pull request: the specs don't mention what endiannes is needed for the bitmask controls: machine endianess, little endian or big endian. IMO, we should stick with either LE or BE. Sorry Sakari, I should have fixed that. But since the patch was going through your repository I forgot about it. Anyway, it should be machine endianess. You have to be able to do (value bit_define). The bit_defines for each bitmask control should be part of the control's definition in videodev2.h. It makes no sense to require LE or BE. We don't do that for other control types, so why should bitmask be any different? Can you add this clarification to DocBook? Thinking about this some more, if we're to say something about the endianness we should specify it for all controls, not just bitmasks. I really wonder if need this at all: why would you think the endianness in a bitmask would be some other than machine endianness, be it a V4L2 control or a flags field in, say, struct v4l2_buffer? It would make sense to document it if it differs from the norm, so in my opinion such statement would be redundant. Because someone might have the bright idea of exposing a hardware register via V4L2_CTRL_TYPE_BITMASK directly without reminding about the endiannes, and do the wrong thing. The same could be done to an integer control as well, the bitmask isn't special in that sense. Just my opinion. The spec says When for example a hardware register accepts values 0-511 and the driver reports 0-65535, step should be 128. on step field in struct v4l2_queryctrl. This suggests that registers may be exposed to user space as integer controls. Yes, in opposite to the V4L1 API, were drivers used to do some internal calculus, in order to meet the API. So endianness issues may exist on other types of controls as well if the programmer didn't remember that other endian than his existed. Yes, that's true, although AFAIKT, this currently doesn't happen. I agree that putting it in a way that it covers all controls are better. There's not much problem on being redundant at the specs, but not specifying it means that different implementations will still be valid. Btw, if you take a look at the descriptions for RGB format at the spec, you'll see that endiannes problems already happened in the past: the specs had to explicitly allow both endiannes for a few RGB formats due to that. I'm ok if we standardize that it should be the machine endiannes, but we should be explicit on that. I'll add a few words on this, but should it be added to bitmask controls documentation or controls in general? Can be in general. Thanks! Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL FOR 3.1] Bitmask controls, flash API and adp1653 driver
On Friday, July 01, 2011 03:27:10 Mauro Carvalho Chehab wrote: Em 10-06-2011 06:27, Sakari Ailus escreveu: Hi Mauro, This pull request adds the bitmask controls, flash API and the adp1653 driver. What has changed since the patches is: - Adp1653 flash faults control is volatile. Fix this. - Flash interface marked as experimental. - Moved the DocBook documentation to a new location. - The target version is 3.1, not 2.6.41. The following changes since commit 75125b9d44456e0cf2d1fbb72ae33c13415299d1: [media] DocBook: Don't be noisy at make cleanmediadocs (2011-06-09 16:40:58 -0300) are available in the git repository at: ssh://linuxtv.org/git/sailus/media_tree.git media-for-3.1 Hans Verkuil (3): v4l2-ctrls: add new bitmask control type. vivi: add bitmask test control. DocBook: document V4L2_CTRL_TYPE_BITMASK. I'm sure I've already mentioned, but I think it was at the Hans pull request: the specs don't mention what endiannes is needed for the bitmask controls: machine endianess, little endian or big endian. IMO, we should stick with either LE or BE. Sorry Sakari, I should have fixed that. But since the patch was going through your repository I forgot about it. Anyway, it should be machine endianess. You have to be able to do (value bit_define). The bit_defines for each bitmask control should be part of the control's definition in videodev2.h. It makes no sense to require LE or BE. We don't do that for other control types, so why should bitmask be any different? Can you add this clarification to DocBook? Regards, Hans Sakari Ailus (3): v4l: Add a class and a set of controls for flash devices. v4l: Add flash control documentation adp1653: Add driver for LED flash controller Documentation/DocBook/media/v4l/compat.xml | 11 + Documentation/DocBook/media/v4l/controls.xml | 283 Documentation/DocBook/media/v4l/v4l2.xml |9 +- .../DocBook/media/v4l/vidioc-g-ext-ctrls.xml |7 + .../DocBook/media/v4l/vidioc-queryctrl.xml | 12 +- drivers/media/video/Kconfig|9 + drivers/media/video/Makefile |1 + drivers/media/video/adp1653.c | 485 drivers/media/video/v4l2-common.c |3 + drivers/media/video/v4l2-ctrls.c | 62 +++- drivers/media/video/vivi.c | 18 +- include/linux/videodev2.h | 37 ++ include/media/adp1653.h| 126 + 13 files changed, 1058 insertions(+), 5 deletions(-) create mode 100644 drivers/media/video/adp1653.c create mode 100644 include/media/adp1653.h -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL FOR 3.1] Bitmask controls, flash API and adp1653 driver
Hi Hans and Mauro, On Fri, Jul 01, 2011 at 09:57:39AM +0200, Hans Verkuil wrote: On Friday, July 01, 2011 03:27:10 Mauro Carvalho Chehab wrote: Em 10-06-2011 06:27, Sakari Ailus escreveu: Hi Mauro, This pull request adds the bitmask controls, flash API and the adp1653 driver. What has changed since the patches is: - Adp1653 flash faults control is volatile. Fix this. - Flash interface marked as experimental. - Moved the DocBook documentation to a new location. - The target version is 3.1, not 2.6.41. The following changes since commit 75125b9d44456e0cf2d1fbb72ae33c13415299d1: [media] DocBook: Don't be noisy at make cleanmediadocs (2011-06-09 16:40:58 -0300) are available in the git repository at: ssh://linuxtv.org/git/sailus/media_tree.git media-for-3.1 Hans Verkuil (3): v4l2-ctrls: add new bitmask control type. vivi: add bitmask test control. DocBook: document V4L2_CTRL_TYPE_BITMASK. I'm sure I've already mentioned, but I think it was at the Hans pull request: the specs don't mention what endiannes is needed for the bitmask controls: machine endianess, little endian or big endian. IMO, we should stick with either LE or BE. Sorry Sakari, I should have fixed that. But since the patch was going through your repository I forgot about it. Anyway, it should be machine endianess. You have to be able to do (value bit_define). The bit_defines for each bitmask control should be part of the control's definition in videodev2.h. No problem, Hans. The bit defines would change from endianness to another if the endianness were to be either big or little. I agree to using machine endianness --- that was also my assumption previously. It makes no sense to require LE or BE. We don't do that for other control types, so why should bitmask be any different? Can you add this clarification to DocBook? Sure I can. Mauro: are you ok with this? Cheers, -- Sakari Ailus sakari.ai...@iki.fi -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL FOR 3.1] Bitmask controls, flash API and adp1653 driver
On Fri, Jul 01, 2011 at 09:57:39AM +0200, Hans Verkuil wrote: On Friday, July 01, 2011 03:27:10 Mauro Carvalho Chehab wrote: Em 10-06-2011 06:27, Sakari Ailus escreveu: Hi Mauro, This pull request adds the bitmask controls, flash API and the adp1653 driver. What has changed since the patches is: - Adp1653 flash faults control is volatile. Fix this. - Flash interface marked as experimental. - Moved the DocBook documentation to a new location. - The target version is 3.1, not 2.6.41. The following changes since commit 75125b9d44456e0cf2d1fbb72ae33c13415299d1: [media] DocBook: Don't be noisy at make cleanmediadocs (2011-06-09 16:40:58 -0300) are available in the git repository at: ssh://linuxtv.org/git/sailus/media_tree.git media-for-3.1 Hans Verkuil (3): v4l2-ctrls: add new bitmask control type. vivi: add bitmask test control. DocBook: document V4L2_CTRL_TYPE_BITMASK. I'm sure I've already mentioned, but I think it was at the Hans pull request: the specs don't mention what endiannes is needed for the bitmask controls: machine endianess, little endian or big endian. IMO, we should stick with either LE or BE. Sorry Sakari, I should have fixed that. But since the patch was going through your repository I forgot about it. Anyway, it should be machine endianess. You have to be able to do (value bit_define). The bit_defines for each bitmask control should be part of the control's definition in videodev2.h. It makes no sense to require LE or BE. We don't do that for other control types, so why should bitmask be any different? Can you add this clarification to DocBook? Thinking about this some more, if we're to say something about the endianness we should specify it for all controls, not just bitmasks. I really wonder if need this at all: why would you think the endianness in a bitmask would be some other than machine endianness, be it a V4L2 control or a flags field in, say, struct v4l2_buffer? It would make sense to document it if it differs from the norm, so in my opinion such statement would be redundant. -- Sakari Ailus sakari.ai...@iki.fi -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL FOR 3.1] Bitmask controls, flash API and adp1653 driver
Em 01-07-2011 08:15, Sakari Ailus escreveu: On Fri, Jul 01, 2011 at 09:57:39AM +0200, Hans Verkuil wrote: On Friday, July 01, 2011 03:27:10 Mauro Carvalho Chehab wrote: Em 10-06-2011 06:27, Sakari Ailus escreveu: Hi Mauro, This pull request adds the bitmask controls, flash API and the adp1653 driver. What has changed since the patches is: - Adp1653 flash faults control is volatile. Fix this. - Flash interface marked as experimental. - Moved the DocBook documentation to a new location. - The target version is 3.1, not 2.6.41. The following changes since commit 75125b9d44456e0cf2d1fbb72ae33c13415299d1: [media] DocBook: Don't be noisy at make cleanmediadocs (2011-06-09 16:40:58 -0300) are available in the git repository at: ssh://linuxtv.org/git/sailus/media_tree.git media-for-3.1 Hans Verkuil (3): v4l2-ctrls: add new bitmask control type. vivi: add bitmask test control. DocBook: document V4L2_CTRL_TYPE_BITMASK. I'm sure I've already mentioned, but I think it was at the Hans pull request: the specs don't mention what endiannes is needed for the bitmask controls: machine endianess, little endian or big endian. IMO, we should stick with either LE or BE. Sorry Sakari, I should have fixed that. But since the patch was going through your repository I forgot about it. Anyway, it should be machine endianess. You have to be able to do (value bit_define). The bit_defines for each bitmask control should be part of the control's definition in videodev2.h. It makes no sense to require LE or BE. We don't do that for other control types, so why should bitmask be any different? Can you add this clarification to DocBook? Thinking about this some more, if we're to say something about the endianness we should specify it for all controls, not just bitmasks. I really wonder if need this at all: why would you think the endianness in a bitmask would be some other than machine endianness, be it a V4L2 control or a flags field in, say, struct v4l2_buffer? It would make sense to document it if it differs from the norm, so in my opinion such statement would be redundant. Because someone might have the bright idea of exposing a hardware register via V4L2_CTRL_TYPE_BITMASK directly without reminding about the endiannes, and do the wrong thing. There's not much problem on being redundant at the specs, but not specifying it means that different implementations will still be valid. Btw, if you take a look at the descriptions for RGB format at the spec, you'll see that endiannes problems already happened in the past: the specs had to explicitly allow both endiannes for a few RGB formats due to that. I'm ok if we standardize that it should be the machine endiannes, but we should be explicit on that. Cheers, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL FOR 3.1] Bitmask controls, flash API and adp1653 driver
Em 10-06-2011 06:27, Sakari Ailus escreveu: Hi Mauro, This pull request adds the bitmask controls, flash API and the adp1653 driver. What has changed since the patches is: - Adp1653 flash faults control is volatile. Fix this. - Flash interface marked as experimental. - Moved the DocBook documentation to a new location. - The target version is 3.1, not 2.6.41. The following changes since commit 75125b9d44456e0cf2d1fbb72ae33c13415299d1: [media] DocBook: Don't be noisy at make cleanmediadocs (2011-06-09 16:40:58 -0300) are available in the git repository at: ssh://linuxtv.org/git/sailus/media_tree.git media-for-3.1 Hans Verkuil (3): v4l2-ctrls: add new bitmask control type. vivi: add bitmask test control. DocBook: document V4L2_CTRL_TYPE_BITMASK. I'm sure I've already mentioned, but I think it was at the Hans pull request: the specs don't mention what endiannes is needed for the bitmask controls: machine endianess, little endian or big endian. IMO, we should stick with either LE or BE. Sakari Ailus (3): v4l: Add a class and a set of controls for flash devices. v4l: Add flash control documentation adp1653: Add driver for LED flash controller Documentation/DocBook/media/v4l/compat.xml | 11 + Documentation/DocBook/media/v4l/controls.xml | 283 Documentation/DocBook/media/v4l/v4l2.xml |9 +- .../DocBook/media/v4l/vidioc-g-ext-ctrls.xml |7 + .../DocBook/media/v4l/vidioc-queryctrl.xml | 12 +- drivers/media/video/Kconfig|9 + drivers/media/video/Makefile |1 + drivers/media/video/adp1653.c | 485 drivers/media/video/v4l2-common.c |3 + drivers/media/video/v4l2-ctrls.c | 62 +++- drivers/media/video/vivi.c | 18 +- include/linux/videodev2.h | 37 ++ include/media/adp1653.h| 126 + 13 files changed, 1058 insertions(+), 5 deletions(-) create mode 100644 drivers/media/video/adp1653.c create mode 100644 include/media/adp1653.h -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PULL FOR 3.1] Bitmask controls, flash API and adp1653 driver
Hi Mauro, This pull request adds the bitmask controls, flash API and the adp1653 driver. What has changed since the patches is: - Adp1653 flash faults control is volatile. Fix this. - Flash interface marked as experimental. - Moved the DocBook documentation to a new location. - The target version is 3.1, not 2.6.41. The following changes since commit 75125b9d44456e0cf2d1fbb72ae33c13415299d1: [media] DocBook: Don't be noisy at make cleanmediadocs (2011-06-09 16:40:58 -0300) are available in the git repository at: ssh://linuxtv.org/git/sailus/media_tree.git media-for-3.1 Hans Verkuil (3): v4l2-ctrls: add new bitmask control type. vivi: add bitmask test control. DocBook: document V4L2_CTRL_TYPE_BITMASK. Sakari Ailus (3): v4l: Add a class and a set of controls for flash devices. v4l: Add flash control documentation adp1653: Add driver for LED flash controller Documentation/DocBook/media/v4l/compat.xml | 11 + Documentation/DocBook/media/v4l/controls.xml | 283 Documentation/DocBook/media/v4l/v4l2.xml |9 +- .../DocBook/media/v4l/vidioc-g-ext-ctrls.xml |7 + .../DocBook/media/v4l/vidioc-queryctrl.xml | 12 +- drivers/media/video/Kconfig|9 + drivers/media/video/Makefile |1 + drivers/media/video/adp1653.c | 485 drivers/media/video/v4l2-common.c |3 + drivers/media/video/v4l2-ctrls.c | 62 +++- drivers/media/video/vivi.c | 18 +- include/linux/videodev2.h | 37 ++ include/media/adp1653.h| 126 + 13 files changed, 1058 insertions(+), 5 deletions(-) create mode 100644 drivers/media/video/adp1653.c create mode 100644 include/media/adp1653.h -- Sakari Ailus sakari.ai...@iki.fi -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
