1. 26 9月, 2012 1 次提交
  2. 15 9月, 2012 1 次提交
  3. 16 8月, 2012 1 次提交
  4. 12 8月, 2012 3 次提交
  5. 31 7月, 2012 2 次提交
  6. 07 7月, 2012 4 次提交
  7. 12 6月, 2012 1 次提交
  8. 15 5月, 2012 2 次提交
  9. 14 5月, 2012 1 次提交
  10. 20 4月, 2012 1 次提交
  11. 11 4月, 2012 1 次提交
  12. 27 3月, 2012 1 次提交
  13. 15 2月, 2012 2 次提交
  14. 27 1月, 2012 1 次提交
  15. 24 1月, 2012 1 次提交
  16. 04 11月, 2011 1 次提交
  17. 21 9月, 2011 1 次提交
  18. 07 9月, 2011 3 次提交
  19. 28 7月, 2011 7 次提交
    • H
    • H
      [media] vivi: Fix sleep-in-atomic-context · 1de5be5e
      Hans Verkuil 提交于
      Fix sleep-in-atomic-context bug in vivi:
      
      Jun 28 18:14:39 tschai kernel: [   80.970478] BUG: sleeping function called from invalid context at kernel/mutex.c:271
      Jun 28 18:14:39 tschai kernel: [   80.970483] in_atomic(): 0, irqs_disabled(): 1, pid: 2854, name: vivi-000
      Jun 28 18:14:39 tschai kernel: [   80.970485] INFO: lockdep is turned off.
      Jun 28 18:14:39 tschai kernel: [   80.970486] irq event stamp: 0
      Jun 28 18:14:39 tschai kernel: [   80.970487] hardirqs last  enabled at (0): [<          (null)>]           (null)
      Jun 28 18:14:39 tschai kernel: [   80.970490] hardirqs last disabled at (0): [<ffffffff8109a90b>] copy_process+0x61b/0x1440
      Jun 28 18:14:39 tschai kernel: [   80.970495] softirqs last  enabled at (0): [<ffffffff8109a90b>] copy_process+0x61b/0x1440
      Jun 28 18:14:39 tschai kernel: [   80.970498] softirqs last disabled at (0): [<          (null)>]           (null)
      Jun 28 18:14:39 tschai kernel: [   80.970502] Pid: 2854, comm: vivi-000 Tainted: P            3.0.0-rc1-tschai #372
      Jun 28 18:14:39 tschai kernel: [   80.970504] Call Trace:
      Jun 28 18:14:39 tschai kernel: [   80.970509]  [<ffffffff81089be3>] __might_sleep+0xf3/0x130
      Jun 28 18:14:39 tschai kernel: [   80.970512]  [<ffffffff8176967f>] mutex_lock_nested+0x2f/0x60
      Jun 28 18:14:39 tschai kernel: [   80.970517]  [<ffffffffa0acee3e>] vivi_fillbuff+0x20e/0x3f0 [vivi]
      Jun 28 18:14:39 tschai kernel: [   80.970520]  [<ffffffff81407004>] ? do_raw_spin_lock+0x54/0x150
      Jun 28 18:14:39 tschai kernel: [   80.970524]  [<ffffffff8104ef5e>] ? read_tsc+0xe/0x20
      Jun 28 18:14:39 tschai kernel: [   80.970528]  [<ffffffff810c9d87>] ? getnstimeofday+0x57/0xe0
      Jun 28 18:14:39 tschai kernel: [   80.970531]  [<ffffffffa0acf1b1>] vivi_thread+0x191/0x2f0 [vivi]
      Jun 28 18:14:39 tschai kernel: [   80.970534]  [<ffffffff81093aa0>] ? try_to_wake_up+0x2d0/0x2d0
      Jun 28 18:14:39 tschai kernel: [   80.970537]  [<ffffffffa0acf020>] ? vivi_fillbuff+0x3f0/0x3f0 [vivi]
      Jun 28 18:14:39 tschai kernel: [   80.970541]  [<ffffffff810bff46>] kthread+0xb6/0xc0
      Jun 28 18:14:39 tschai kernel: [   80.970544]  [<ffffffff817743e4>] kernel_thread_helper+0x4/0x10
      Jun 28 18:14:39 tschai kernel: [   80.970547]  [<ffffffff8176b4d4>] ? retint_restore_args+0x13/0x13
      Jun 28 18:14:39 tschai kernel: [   80.970550]  [<ffffffff810bfe90>] ? __init_kthread_worker+0x70/0x70
      Jun 28 18:14:39 tschai kernel: [   80.970552]  [<ffffffff817743e0>] ? gs_change+0x13/0x13
      
      This bug was introduced in 2.6.39.
      Signed-off-by: NHans Verkuil <hans.verkuil@cisco.com>
      Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
      1de5be5e
    • H
      [media] v4l2-event/ctrls/fh: allocate events per fh and per type instead of just per-fh · f1e393de
      Hans Verkuil 提交于
      The driver had to decide how many events to allocate when the v4l2_fh struct
      was created. It was possible to add more events afterwards, but there was no
      way to ensure that you wouldn't miss important events if the event queue
      would fill up for that filehandle.
      
      In addition, once there were no more free events, any new events were simply
      dropped on the floor.
      
      For the control event in particular this made life very difficult since
      control status/value changes could just be missed if the number of allocated
      events and the speed at which the application read events was too low to keep
      up with the number of generated events. The application would have no idea
      what the latest state was for a control since it could have missed the latest
      control change.
      
      So this patch makes some major changes in how events are allocated. Instead
      of allocating events per-filehandle they are now allocated when subscribing an
      event. So for that particular event type N events (determined by the driver)
      are allocated. Those events are reserved for that particular event type.
      This ensures that you will not miss events for a particular type altogether.
      
      In addition, if there are N events in use and a new event is raised, then
      the oldest event is dropped and the new one is added. So the latest event
      is always available.
      
      This can be further improved by adding the ability to merge the state of
      two events together, ensuring that no data is lost at all. This will be
      added in the next patch.
      
      This also makes it possible to allow the user to determine the number of
      events that will be allocated. This is not implemented at the moment, but
      would be trivial.
      Signed-off-by: NHans Verkuil <hans.verkuil@cisco.com>
      Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
      f1e393de
    • H
      [media] v4l2-events/fh: merge v4l2_events into v4l2_fh · 523f46d6
      Hans Verkuil 提交于
      Drivers that supported events used to be rare, but now that controls can also
      raise events this will become much more common since almost all drivers have
      controls.
      
      This means that keeping struct v4l2_events as a separate struct make no more
      sense. Merging it into struct v4l2_fh simplifies things substantially as it
      is now an integral part of the filehandle struct.
      Signed-off-by: NHans Verkuil <hans.verkuil@cisco.com>
      Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
      523f46d6
    • H
      c7a52f8d
    • H
    • M
      [media] Stop using linux/version.h on most video drivers · 1990d50b
      Mauro Carvalho Chehab 提交于
      All the modified drivers didn't have any version increment since
      Jan, 1 2011. Several of them didn't have any version increment
      for a long time, even having new features and important bug fixes
      happening.
      
      As we're now filling the QUERYCAP version with the current Kernel
      Release, we don't need to maintain a per-driver version control
      anymore. So, let's just use the default.
      
      In order to preserve the Kernel module version history, a
      KERNEL_VERSION() macro were added to all modified drivers, and
      the extraver number were incremented.
      
      I opted to preserve the per-driver version control to a few
      pwc, pvrusb2, s2255, s5p-fimc and sh_vou.
      
      A few drivers are still using the legacy way to handle ioctl's.
      So, we can't do such change on them, otherwise, they'll break.
      Those are: uvc, et61x251 and sn9c102.
      
      The rationale is that the per-driver version control seems to be
      actively maintained on those.
      
      Yet, I think that the better for them would be to just use the
      default version numbering, instead of doing that by themselves.
      
      While here, removed a few uneeded include linux/version.h
      Acked-by: NHans Verkuil <hans.verkuil@cisco.com>
      Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
      1990d50b
  20. 23 3月, 2011 2 次提交
  21. 22 3月, 2011 3 次提交