Skip to content

cloud-kernel
cloud-kernel

openanolis / cloud-kernel
1 年多 前同步成功

通知 165
Star 36
Fork 7
cloud-kernel
cloud-kernel
切换分支/标签
  1. 17 7月, 2014 4 次提交
  3. 17 10月, 2013 1 次提交
  5. 03 9月, 2013 1 次提交
  7. 26 7月, 2013 1 次提交
  9. 24 3月, 2013 1 次提交
    • A
      [media] v4l2-ctrls: eliminate lockdep false alarms for struct v4l2_ctrl_handler.lock · 6cd247ef
      由 Andy Walls 提交于 
      When calling v4l2_ctrl_add_handler(), lockdep would detect a potential
recursive locking problem on a situation that is by design intended and
not a recursive lock.  This happened because all struct
v4l2_ctrl_handler.lock mutexes were created as members of the same lock
class in v4l2_ctrl_handler_init(), and v4l2_ctrl_add_handler() takes the
hdl->lock on two different v4l2_ctrl_handler instances.
This change breaks the large lockdep lock class for struct
v4l2_ctrl_handler.lock and breaks it into v4l2_ctrl_handler
instantiation specific lock classes with meaningful class names.
This will validly eliminate lockdep alarms for v4l2_ctrl_handler locking
validation, as long as the relationships between drivers adding v4l2
controls to their own handler from other v4l2 drivers' control handlers
remains straightforward.
struct v4l2_ctrl_handler.lock lock classes are created with names such
that the output of cat /proc/lockdep indicates where in the v4l2 driver
code v4l2_ctrl_handle_init() is being called on instantiations:
ffffffffa045f490 FD:   10 BD:    8 +.+...: cx2341x:1534:(hdl)->lock
ffffffffa0497d20 FD:   12 BD:    2 +.+.+.: saa7115:1581:(hdl)->lock
ffffffffa04ac660 FD:   14 BD:    2 +.+.+.: msp3400_driver:756:(hdl)->lock
ffffffffa0484b90 FD:   12 BD:    1 +.+.+.: ivtv_gpio:366:(&itv->hdl_gpio)->lock
ffffffffa04eb530 FD:   11 BD:    2 +.+.+.: cx25840_core:1982:(&state->hdl)->lock
ffffffffa04fbc80 FD:   11 BD:    3 +.+.+.: wm8775:246:(&state->hdl)->lock
Some lock chains, that were previously causing the recursion alarms, are
now visible in the output of cat /proc/lockdep_chains:
irq_context: 0
[ffffffffa0497d20] saa7115:1581:(hdl)->lock
[ffffffffa045f490] cx2341x:1534:(hdl)->lock
irq_context: 0
[ffffffffa04ac660] msp3400_driver:756:(hdl)->lock
[ffffffffa045f490] cx2341x:1534:(hdl)->lock
irq_context: 0
[ffffffffa0484b90] ivtv_gpio:366:(&itv->hdl_gpio)->lock
[ffffffffa045f490] cx2341x:1534:(hdl)->lock
irq_context: 0
[ffffffffa04eb530] cx25840_core:1982:(&state->hdl)->lock
[ffffffffa045f490] cx2341x:1534:(hdl)->lock
irq_context: 0
[ffffffffa04fbc80] wm8775:246:(&state->hdl)->lock
[ffffffffa045f490] cx2341x:1534:(hdl)->lock
Signed-off-by: NAndy Walls <awalls@md.metrocast.net>
[hans.verkuil@cisco.com: keep mutex_init in v4l2_ctrl_handler_init_class]
Signed-off-by: NHans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
      6cd247ef
  11. 06 2月, 2013 3 次提交
  13. 05 1月, 2013 1 次提交
  15. 06 10月, 2012 1 次提交
  17. 02 10月, 2012 1 次提交
  19. 26 9月, 2012 1 次提交
  21. 14 9月, 2012 1 次提交
  23. 15 5月, 2012 2 次提交
  25. 14 5月, 2012 1 次提交
  27. 08 5月, 2012 1 次提交
  29. 20 4月, 2012 1 次提交
  31. 11 4月, 2012 1 次提交
  33. 16 3月, 2012 1 次提交
    • P
      device.h: audit and cleanup users in main include dir · 313162d0
      由 Paul Gortmaker 提交于 
      The <linux/device.h> header includes a lot of stuff, and
it in turn gets a lot of use just for the basic "struct device"
which appears so often.

Clean up the users as follows:

1) For those headers only needing "struct device" as a pointer
in fcn args, replace the include with exactly that.

2) For headers not really using anything from device.h, simply
delete the include altogether.

3) For headers relying on getting device.h implicitly before
being included themselves, now explicitly include device.h

4) For files in which doing #1 or #2 uncovers an implicit
dependency on some other header, fix by explicitly adding
the required header(s).

Any C files that were implicitly relying on device.h to be
present have already been dealt with in advance.

Total removals from #1 and #2: 51.  Total additions coming
from #3: 9.  Total other implicit dependencies from #4: 7.

As of 3.3-rc1, there were 110, so a net removal of 42 gives
about a 38% reduction in device.h presence in include/*
Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com>
      313162d0
  35. 15 2月, 2012 2 次提交
  37. 21 9月, 2011 2 次提交
    • H
      [media] v4l2-ctrls: implement new volatile autocluster scheme · 5626b8c7
      由 Hans Verkuil 提交于 
      The problem tackled in this patch is how to handle volatile autoclusters
correctly. A volatile autocluster is a cluster of related controls where one
control is the control that toggles between manual and auto mode and the other
controls are the values for the manual mode. For example autogain and gain,
autoexposure and exposure, etc.

If the hardware lets you read out the automatically calculated manual values
while in automode, then those manual controls should be marked volatile.

gain value as calculated by the autogain circuitry, then you would mark the
gain control as volatile (i.e. continuously changing).

The question in such use cases is what to do when switching from the auto
mode to the manual mode. Should we switch to the last set manual values or
should the volatile values be copied and used as the initial manual values.

For example: suppose the mode is manual gain and gain is set to 5. Then
autogain is turned on and the gain is set by the hardware to 2. Finally
the user switches back to manual gain. What should the gain be? 2 or 5?

After a long discussion the decisions was made to keep the last value as
calculated by the auto mode (so 2 in the example above).

The reason is that webcams that do such things will adapt themselves to
the current light conditions and when you switch back to manual mode you
expect that you keep the same picture. If you would switch back to old
manual values, then that would give you a suddenly different picture,
which is jarring for the user.

Additionally, this would be difficult to implement in applications that
store and restore the control values at application exit and start.

If you want to keep the old manual values when you switch from auto to
manual, then there would have to be a way for applications to get hold
of those old values while in auto mode, but there isn't.

So this patch will do all the heavy lifting in v4l2-ctrls.c: if you go
from auto mode to manual mode and the manual controls are volatile, then
g_volatile_ctrl will be called to get the current values for the manual
controls before switching to manual mode.
Signed-off-by: NHans Verkuil <hans.verkuil@cisco.com>
Acked-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
      5626b8c7
    • H
      [media] v4l2-ctrls: replace is_volatile with V4L2_CTRL_FLAG_VOLATILE · 88365105
      由 Hans Verkuil 提交于 
      With the new flag there is no need anymore to have a separate is_volatile
field. Modify all users to use the new flag.
Signed-off-by: NHans Verkuil <hans.verkuil@cisco.com>
Acked-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
      88365105
  39. 28 7月, 2011 9 次提交
  41. 19 1月, 2011 2 次提交
  43. 30 12月, 2010 1 次提交
  45. 09 8月, 2010 1 次提交
    • H
      V4L/DVB: v4l2: Add new control handling framework · 0996517c
      由 Hans Verkuil 提交于 
      Add a new framework to handle controls which makes life for driver
developers much easier.

Note that this patch moves some of the control support that used to be in
v4l2-common.c to v4l2-ctrls.c. The tables were copied unchanged. The body
of v4l2_ctrl_query_fill() was copied to a new v4l2_ctrl_fill() function
in v4l2-ctrls.c. This new function doesn't use the v4l2_queryctrl
struct anymore, which makes it more general.

The remainder of v4l2-ctrls.c is all new. Highlights include:

- No need to implement VIDIOC_QUERYCTRL, QUERYMENU, S_CTRL, G_CTRL,
  S_EXT_CTRLS, G_EXT_CTRLS or TRY_EXT_CTRLS in either bridge drivers
  or subdevs. New wrapper functions are provided that can just be plugged in.
  Once everything has been converted these wrapper functions can be removed as well.

- When subdevices are added their controls can be automatically merged
  with the bridge driver's controls.

- Most drivers just need to implement s_ctrl to set the controls.
  The framework handles the locking and tries to be as 'atomic' as possible.

- Ready for the subdev device nodes: the same mechanism applies to subdevs
  and their device nodes as well. Sub-device drivers can make controls
  local, preventing them from being merged with bridge drivers.

- Takes care of backwards compatibility handling of VIDIOC_S_CTRL and
  VIDIOC_G_CTRL. Handling of V4L2_CID_PRIVATE_BASE is fully transparent.
  CTRL_CLASS controls are automatically added.
Signed-off-by: NHans Verkuil <hverkuil@xs4all.nl>
Reviewed-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
      0996517c