Skip to content

cloud-kernel
cloud-kernel

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

通知 165
Star 36
Fork 7
cloud-kernel
cloud-kernel
切换分支/标签
  1. 28 7月, 2011 3 次提交
    • D
      [media] cx231xx: Fix power ramping issue · 44ecf1df
      由 Devin Heitmueller 提交于 
      On platforms that have CONFIG_HZ set to 100, the power ramp time effectively
ends up being 10ms.  However, on those that have a higher CONFIG_HZ, the time
ends up *actually* being 5ms, which doesn't allow enough time for the hardware
to be fully powered up before attempting to address it via i2c.

Change the constant to 10ms, which is long enough for the hardware to power
up, and won't really be anymore time than it was previously on platforms
with CONFIG_HZ being 100.

Credit goes to Mauro Carvalho Chehab and Gerd Hoffmann who previously
investigated this issue.

Tested with the Hauppauge USBLive 2, with which the problem was readily
reproducible after setting CONFIG_HZ to 1000.
Signed-off-by: NDevin Heitmueller <dheitmueller@kernellabs.com>
Cc: Mauro Carvalho Chehab <mchehab@redhat.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
      44ecf1df
    • 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
    • P
      [media] cx231xx: Add support for Hauppauge WinTV USB2-FM · de8ae0d5
      由 Peter Moon 提交于 
      This patch adds support for the "Hauppauge WinTV USB2-FM" Analog TV Stick.
It includes support for both the PAL and NTSC variants of the device.
Signed-off-by: NPeter Moon <pomoon@gmail.com>
Reviewed-by: NDevin Heitmueller <dheitmueller@hauppauge.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
      de8ae0d5
  3. 21 5月, 2011 1 次提交
  5. 20 5月, 2011 1 次提交
  7. 22 3月, 2011 4 次提交
  9. 29 12月, 2010 7 次提交
  11. 21 10月, 2010 12 次提交
  13. 19 5月, 2010 1 次提交
  15. 16 12月, 2009 1 次提交
  17. 12 9月, 2009 1 次提交
    • M
      V4L/DVB (12595): common/ir: use a struct for keycode tables · 715a2233
      由 Mauro Carvalho Chehab 提交于 
      Currently, V4L uses a scancode table whose index is the scancode and
the value is the keycode. While this works, it has some drawbacks:

1) It requires that the scancode to be at the range 00-7f;

2) keycodes should be masked on 7 bits in order for it to work;

3) due to the 7 bits approach, sometimes it is not possible to replace
the default keyboard to another one with a different encoding rule;

4) it is different than what is done with dvb-usb approach;

5) it requires a typedef for it to work. This is not a recommended
Linux CodingStyle.

This patch is part of a larger series of IR changes. It basically
replaces the IR_KEYTAB_TYPE tables by a structured table:
struct ir_scancode {
       u16     scancode;
       u32     keycode;
};

This is very close to what dvb does. So, a further integration with DVB
code will be easy.

While we've changed the tables, for now, the IR keycode handling is still
based on the old approach.

The only notable effect is the redution of about 35% of the ir-common
module size:

   text    data     bss     dec     hex filename
   6721   29208       4   35933    8c5d old/ir-common.ko
   5756   18040       4   23800    5cf8 new/ir-common.ko

In thesis, we could be using above u8 for scancode, reducing even more the size
of the module, but defining it as u16 is more convenient, since, on dvb, each
scancode has up to 16 bits, and we currently have a few troubles with rc5, as their
scancodes are defined with more than 8 bits.

This patch itself shouldn't be doing any functional changes.
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
      715a2233
  19. 23 6月, 2009 1 次提交
    • T
      V4L/DVB (11913): cx231xx: TRY_FMT should not actually set anything · 1ca27379
      由 Trent Piepho 提交于 
      In the TRY_FMT handler the function get_scale() is called to find what the
scaler hardware will produce for a requested size.

The problem is that get_scale(struct cx231xx *dev, ..., unsigned int *vscale,
unsigned int *hscale) saves the calculated scale values into both the
pointer arguments and into dev's hscale and vscale fields.  TRY_FMT shouldn't
actually change anything in the device state.

The code to in get_scale() that writes to dev->[hv]scale can just be
deleted.  In all cases when dev's fields should be modified, get_scale()
was called with get_scale(dev, ..., &dev->hscale, &dev->vscale), so dev was
getting updated anyway.

This didn't actually cause a problem because nothing ever actually made use
of the hscale and vscale fields.  I changed cx231xx_resolution_set() to use
those fields rather than re-calculate them with a call to get_scale().

Updating [hv]scale in cx231xx_resolution_set() isn't necessary because
every call of cx231xx_resolution_set() was already preceded by a call to
get_scale() or setting the [hv]scale fields, so they will be always be
up-to-date w.r.t. width and height.

Removing the call to get_scale() from cx231xx_resolution_set() allowed
making get_scale() a static function, which is a good thing for something
with such a short name.  There is already another function with the same
name in the em28xx driver, but that one is static.
Signed-off-by: NTrent Piepho <xyzzy@speakeasy.org>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
      1ca27379
  21. 17 6月, 2009 2 次提交
  23. 07 4月, 2009 6 次提交