Skip to content

cloud-kernel
cloud-kernel

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

通知 160
Star 36
Fork 7
cloud-kernel
cloud-kernel
切换分支/标签
  1. 14 2月, 2012 2 次提交
  3. 24 1月, 2012 1 次提交
  5. 16 1月, 2012 2 次提交
  7. 01 6月, 2011 1 次提交
  9. 23 3月, 2011 1 次提交
  11. 09 8月, 2010 1 次提交
  13. 03 8月, 2010 2 次提交
    • I
      V4L/DVB: ivtv: Automatic firmware reload · 215659d1
      由 Ian Armstrong 提交于 
      If the firmware has failed, this patch will automatically reload &
restart the card. The previous card state will be restored on a
successful restart.  Firmware reload will only happen if neither the
encoder or decoder is active.  If the card is busy then behaviour is as
before, returning -EIO on device access until the reload can occur. On
cards that support video output, coloured bars will be displayed during
the reload.

Andy Walls (ivtv maintainer and patch committer) made minor tweaks to
comments and the logged messages, but nothing substantial otherwise.
Signed-off-by: NIan Armstrong <ian@iarmst.demon.co.uk>
Signed-off-by: NAndy Walls <awalls@md.metrocast.net>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
      215659d1
    • I
      V4L/DVB: ivtv: Add firmare monitoring and debug mode to ignore firmware problems · 914610e8
      由 Ian Armstrong 提交于 
      >From Ian's e-mail:
When a device is opened the firmware state will be checked. If it isn't
responding then the open will fail with -EIO.  Due to the nature of the
hardware, a single failed check will block everything since we don't know
exactly what has failed. A side effect of this is the blocking of debug
access, so an additional debug level has been created which allows the block
to be bypassed.

Andy Walls' modifications:
I modified Ian's patch to add a separate fw_debug module parameter to change
the driver's behavior, as opposed to using the normal debug module parameter.
The fw_debug module parameter is only available when CONFIG_VIDEO_ADV_DEBUG
is set.
I also made some minor whitespace adjustments and changed some warning
messages to be a bit more specific.  s/happy/glad/g
Signed-off-by: NIan Armstrong <ian@iarmst.demon.co.uk>
Signed-off-by: NAndy Walls <awalls@md.metrocast.net>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
      914610e8
  15. 09 7月, 2010 1 次提交
  17. 01 6月, 2010 2 次提交
  19. 19 5月, 2010 2 次提交
  21. 18 5月, 2010 2 次提交
  23. 27 2月, 2010 2 次提交
    • A
      V4L/DVB: ivtv: Adjust msleep() delays used to prevent tinny audio and PCI bus hang · 95480f27
      由 Andy Walls 提交于 
      Martin Dauskardt <martin.dauskardt@gmx.de> has done extensive testing on what
values can be used and and concluded that only 300 ms total is required to
avoid bad video effects such as occasional black screen and short sync
disturbances.  Furthermore he determined how this 300 ms was split between
the two msleep()s did matter very much, so he suggested 150ms/150ms as one
acceptable alternative that is implemented here.

Many thanks go to Martin.
Tested-by: NMartin Dauskardt <martin.dauskardt@gmx.de>
Signed-off-by: NAndy Walls <awalls@radix.net>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
      95480f27
    • A
      V4L/DVB: cx25840, v4l2-subdev, ivtv, pvrusb2: Fix ivtv/cx25840 tinny audio · 3ccc646b
      由 Andy Walls 提交于 
      This change attempts to fix the ivtv tinny audio problem by keeping digitizer
to encoder audio clocks running, while disabling the video clocks as needed to
avoid unpredictable PCI bus hangs.

To accomplish this, for the cx25840 module enabling of audio streaming had
to be separated from enabling video streaming, requiring an additional
v4l2_subdev_audio_op and calls to this new op in the pvrusb2 and ivtv drivers.

The cx231xx and cx23885 driver use the cx25840 module for affecting only
video on s_stream calls, so those drivers needed no change.

The CX23418 hardware does not exhibit either the tinny audio problem nor the PCI
bus hang, so the cx18 driver did not need corresponding changes.

CX2341[56] based cards that are not using the CX2584x family of chips
do not seem to be affected by the tinny audio problem, and this change should
not affect how they are configured. It will delay their first capture by
starting by another 300 msec though.

Many thanks go to Argus <pthorn-ivtvd@styx2002.no-ip.org> and
Martin Dauskardt <martin.dauskardt@gmx.de> whose persistent testing and
investigation of this problem will hopefully fix this problem once and for all
for many ivtv users.
Reported-by: NMartin Dauskardt <martin.dauskardt@gmx.de>
Reported-by: NArgus <pthorn-ivtvd@styx2002.no-ip.org>
Signed-off-by: NAndy Walls <awalls@radix.net>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
      3ccc646b
  25. 16 12月, 2009 1 次提交
  27. 19 9月, 2009 2 次提交
  29. 30 3月, 2009 1 次提交
  31. 03 1月, 2009 1 次提交
  33. 30 12月, 2008 2 次提交
  35. 22 10月, 2008 1 次提交
  37. 13 10月, 2008 1 次提交
  39. 12 10月, 2008 1 次提交
    • H
      V4L/DVB (9133): v4l: disconnect kernel number from minor · dd89601d
      由 Hans Verkuil 提交于 
      The v4l core creates four different video devices (video, vbi, radio, vtx)
and each has its own range of minor numbers. However, modern devices keep
increasing the number of devices that they need so a maximum of 64 video
devices will not be enough in the future. In addition this scheme makes
it very hard to add new device types.

This patch disconnects the kernel number allocation (e.g. video0, video1,
etc.) from the actual minor number (just pick the first free minor).

This allows for much more flexibility in the future. However, it does
require the use of udev. For those who cannot use udev a new CONFIG option
was created that changes the allocation scheme back to the old behavior.

Thanks to Greg KH for suggesting this approach during the 2008 LPC.

In addition, several bugs were fixed in the ivtv and cx18 drivers: these
drivers try to allocate specific kernel numbers but that scheme contained
a bug which caused what should have been e.g. video17 to appear as e.g.
video2.
Signed-off-by: NHans Verkuil <hverkuil@xs4all.nl>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
      dd89601d
  41. 04 9月, 2008 1 次提交
  43. 27 7月, 2008 1 次提交
  45. 24 7月, 2008 1 次提交
  47. 20 7月, 2008 3 次提交
  49. 05 6月, 2008 1 次提交
  51. 14 5月, 2008 1 次提交
  53. 25 4月, 2008 1 次提交
  55. 26 1月, 2008 2 次提交
    • R
      V4L/DVB (6776): ivtv: Some general fixes · 14d5deba
      由 Richard Knutsson 提交于 
      Fix "warning: Using plain integer as NULL pointer".
Convert 'x < y ? x : y' to use min() instead.
Signed-off-by: NRichard Knutsson <ricknu-0@student.ltu.se>
Signed-off-by: NHans Verkuil <hverkuil@xs4all.nl>
Signed-off-by: NMauro Carvalho Chehab <mchehab@infradead.org>
      14d5deba
    • I
      V4L/DVB (6717): ivtv: Initial merge of video48 yuv handling into the IVTV_IOC_DMA_FRAME framework · 77aded6b
      由 Ian Armstrong 提交于 
      Previously, all yuv data written to /dev/video48 had only basic support with
no double buffering to avoid display tearing.

With this patch, yuv frames written to video48 are now handled by the existing
IVTV_IOC_DMA_FRAME framework. As such, the frames are hardware buffered to
avoid tearing, and honour scaling mode & field order options. Unlike the
proprietary IVTV_IOC_DMA_FRAME ioctl, all parameters are controlled by the
V4L2 API.

Due to mpeg & yuv output restrictions being different, their V4L2 output
controls have been separated. To control the yuv output, the V4L2 calls must
be done via video48.

If the ivtvfb module is loaded, there will be one side effect to this merge.
The yuv output window will be constrained to the visible framebuffer area. In
the event that a virtual framebuffer size is being used, the limit to the
output size will be the virtual dimensions, but only the portion that falls
within the currently visible area of the framebuffer will be shown.

Like the IVTV_IOC_DMA_FRAME ioctl, the supplied frames must be padded to 720
pixels wide. However the height must only be padded up the nearest multiple
of 32. This would mean an image of 102 lines must be padded to 128. As long
as the true source image size is given, the padding will not be visible in
the final output.
Signed-off-by: NIan Armstrong <ian@iarmst.demon.co.uk>
Signed-off-by: NHans Verkuil <hverkuil@xs4all.nl>
Signed-off-by: NMauro Carvalho Chehab <mchehab@infradead.org>
      77aded6b