21 Dec, 2011

1 commit


31 Mar, 2011

1 commit


25 Mar, 2011

1 commit

  • * 'v4l_for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-2.6: (442 commits)
    [media] videobuf2-dma-contig: make cookie() return a pointer to dma_addr_t
    [media] sh_mobile_ceu_camera: Do not call vb2's mem_ops directly
    [media] V4L: soc-camera: explicitly require V4L2_BUF_TYPE_VIDEO_CAPTURE
    [media] v4l: soc-camera: Store negotiated buffer settings
    [media] rc: interim support for 32-bit NEC-ish scancodes
    [media] mceusb: topseed 0x0011 needs gen3 init for tx to work
    [media] lirc_zilog: error out if buffer read bytes != chunk size
    [media] lirc: silence some compile warnings
    [media] hdpvr: use same polling interval as other OS
    [media] ir-kbd-i2c: pass device code w/key in hauppauge case
    [media] rc/keymaps: Remove the obsolete rc-rc5-tv keymap
    [media] remove the old RC_MAP_HAUPPAUGE_NEW RC map
    [media] rc/keymaps: Rename Hauppauge table as rc-hauppauge
    [media] rc-rc5-hauppauge-new: Fix Hauppauge Grey mapping
    [media] rc-rc5-hauppauge-new: Add support for the old Black RC
    [media] rc-rc5-hauppauge-new: Add the old control to the table
    [media] rc-winfast: Fix the keycode tables
    [media] a800: Fix a few wrong IR key assignments
    [media] opera1: Use multimedia keys instead of an app-specific mapping
    [media] dw2102: Use multimedia keys instead of an app-specific mapping
    ...

    Fix up trivial conflicts (remove/modify and some real conflicts) in:
    arch/arm/mach-omap2/devices.c
    drivers/staging/Kconfig
    drivers/staging/Makefile
    drivers/staging/dabusb/dabusb.c
    drivers/staging/dabusb/dabusb.h
    drivers/staging/easycap/easycap_ioctl.c
    drivers/staging/usbvideo/usbvideo.c
    drivers/staging/usbvideo/vicam.c

    Linus Torvalds
     

22 Mar, 2011

2 commits

  • Those ioctls were produced by the wrong arguments for _IO macros,
    and were replaced by fixed versions on an early 2.6 kernel.

    Signed-off-by: Mauro Carvalho Chehab

    Mauro Carvalho Chehab
     
  • Remove incorrect Matrox G200eV support that was previously added by
    commit e3a1938805d2e81b27d3d348788644f3bad004f2

    A serious issue with the incorrect G200eV support that reproduces on the
    Matrox G200eV equipped IBM x3650 M2 is the total lack of text (login
    banner, login prompt, etc) on the console when X is not running and
    total lack of text on all of the virtual consoles after X is started.

    Any concerns that the incorrect code (upstream since October 2008) has
    been successfully used on non-IBM G200eV equipped system(s) appear to be
    unwarranted. In addition to the serious/non-intermittent nature of
    issues that have been spotted on IBM systems, complete removal of the
    incorrect code is clearly supported by the following Matrox (Yannick
    Heneault) provided input:
    "It impossible that this patch should have work on a system.
    The patch only declare the G200eV as a regular G200 which is
    not case. Many registers are different, including at least the
    PLL programming sequence. If the G200eV is programmed like a
    regular G200, it will not display anything."

    v1 - Initial patch that removed the incorrect code for _all_
    G200eV equipped systems.
    v2 - Darrick Wong provided patch that blacklisted the incorrect
    code on G200eV equipped IBM systems leaving it enabled on
    all G200eV equipped non-IBM systems.
    v3 - Same code changes included with v1 plus additional
    justification for complete removal of the incorrect code.

    Signed-off-by: Gary Hade
    Cc: Darrick J. Wong
    Cc: Krzysztof Helt
    Cc: Petr Vandrovec
    Cc: Andrew Morton
    Cc: Linus Torvalds
    Cc: Yannick Heneault
    Cc: Christian Toutant
    Signed-off-by: Linus Torvalds

    Gary Hade
     

11 Jan, 2011

1 commit

  • Configuring the kernel I found that the Matrox frame buffer help has a
    different option than the one in the docs (Documentation/fb/matroxfb.txt).
    I decided to check the source code to see what is the correct option.
    drivers/video/matrox/matroxfb_base.c has a lot of comments that sugests
    that the video option is "matrox".
    However in line 2452 of this same file you have:
    fb_get_options("matroxfb", &option)

    video=matroxfb:XXX is the correct video option not video=matrox:XXX.

    Signed-off-by: Vicente Jimenez Aguilar
    Signed-off-by: Paul Mundt

    Vicente Jiménez
     

28 Oct, 2010

2 commits


21 Aug, 2010

1 commit

  • Screen is completely corrupted since 2.6.34. Bisection revealed that it's
    caused by commit 6175ddf06b61720 ("x86: Clean up mem*io functions.").

    H. Peter Anvin explained that memcpy_toio() does not copy data in 32bit
    chunks anymore on x86.

    Signed-off-by: Ondrej Zary
    Cc: Brian Gerst
    Cc: H. Peter Anvin
    Cc: Petr Vandrovec
    Cc: Jean Delvare
    Cc: [2.6.34.x, 2.6.35.x]
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Ondrej Zary
     

12 Aug, 2010

1 commit


30 Mar, 2010

1 commit

  • …it slab.h inclusion from percpu.h

    percpu.h is included by sched.h and module.h and thus ends up being
    included when building most .c files. percpu.h includes slab.h which
    in turn includes gfp.h making everything defined by the two files
    universally available and complicating inclusion dependencies.

    percpu.h -> slab.h dependency is about to be removed. Prepare for
    this change by updating users of gfp and slab facilities include those
    headers directly instead of assuming availability. As this conversion
    needs to touch large number of source files, the following script is
    used as the basis of conversion.

    http://userweb.kernel.org/~tj/misc/slabh-sweep.py

    The script does the followings.

    * Scan files for gfp and slab usages and update includes such that
    only the necessary includes are there. ie. if only gfp is used,
    gfp.h, if slab is used, slab.h.

    * When the script inserts a new include, it looks at the include
    blocks and try to put the new include such that its order conforms
    to its surrounding. It's put in the include block which contains
    core kernel includes, in the same order that the rest are ordered -
    alphabetical, Christmas tree, rev-Xmas-tree or at the end if there
    doesn't seem to be any matching order.

    * If the script can't find a place to put a new include (mostly
    because the file doesn't have fitting include block), it prints out
    an error message indicating which .h file needs to be added to the
    file.

    The conversion was done in the following steps.

    1. The initial automatic conversion of all .c files updated slightly
    over 4000 files, deleting around 700 includes and adding ~480 gfp.h
    and ~3000 slab.h inclusions. The script emitted errors for ~400
    files.

    2. Each error was manually checked. Some didn't need the inclusion,
    some needed manual addition while adding it to implementation .h or
    embedding .c file was more appropriate for others. This step added
    inclusions to around 150 files.

    3. The script was run again and the output was compared to the edits
    from #2 to make sure no file was left behind.

    4. Several build tests were done and a couple of problems were fixed.
    e.g. lib/decompress_*.c used malloc/free() wrappers around slab
    APIs requiring slab.h to be added manually.

    5. The script was run on all .h files but without automatically
    editing them as sprinkling gfp.h and slab.h inclusions around .h
    files could easily lead to inclusion dependency hell. Most gfp.h
    inclusion directives were ignored as stuff from gfp.h was usually
    wildly available and often used in preprocessor macros. Each
    slab.h inclusion directive was examined and added manually as
    necessary.

    6. percpu.h was updated not to include slab.h.

    7. Build test were done on the following configurations and failures
    were fixed. CONFIG_GCOV_KERNEL was turned off for all tests (as my
    distributed build env didn't work with gcov compiles) and a few
    more options had to be turned off depending on archs to make things
    build (like ipr on powerpc/64 which failed due to missing writeq).

    * x86 and x86_64 UP and SMP allmodconfig and a custom test config.
    * powerpc and powerpc64 SMP allmodconfig
    * sparc and sparc64 SMP allmodconfig
    * ia64 SMP allmodconfig
    * s390 SMP allmodconfig
    * alpha SMP allmodconfig
    * um on x86_64 SMP allmodconfig

    8. percpu.h modifications were reverted so that it could be applied as
    a separate patch and serve as bisection point.

    Given the fact that I had only a couple of failures from tests on step
    6, I'm fairly confident about the coverage of this conversion patch.
    If there is a breakage, it's likely to be something in one of the arch
    headers which should be easily discoverable easily on most builds of
    the specific arch.

    Signed-off-by: Tejun Heo <tj@kernel.org>
    Guess-its-ok-by: Christoph Lameter <cl@linux-foundation.org>
    Cc: Ingo Molnar <mingo@redhat.com>
    Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>

    Tejun Heo
     

16 Dec, 2009

1 commit

  • Regression caused in 2.6.23 and then despite repeated requests never fixed
    or dealt with (Petr promised to sort it in 2008 but seems to have
    forgotten).

    Enough is enough - remove the problem line that was added. If it upsets
    someone they've had two years to deal with it and at the very least it'll
    rattle their cage and wake them up.

    Addresses http://bugzilla.kernel.org/show_bug.cgi?id=9709

    Signed-off-by: Alan Cox
    Reported-by: Damon
    Tested-by: Ruud van Melick
    Cc: Petr Vandrovec
    Cc: Pekka Enberg
    Cc: Paul A. Clarke
    Cc:
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Alan Cox
     

23 Sep, 2009

5 commits

  • CONFIG_FB_MATROX_32MB is always enabled, so there is no point in having
    ifdefs all around. And it is bad practice to use CONFIG_* as a name for
    something which is not a Kconfig option.

    Signed-off-by: Jean Delvare
    Acked-by: Petr Vandrovec
    Cc: Krzysztof Helt
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Jean Delvare
     
  • With multihead support always enabled, macros MINFO_FROM and
    MINFO_FROM_INFO are no longer needed and make the code harder to read.

    Signed-off-by: Jean Delvare
    Acked-by: Petr Vandrovec
    Cc: Krzysztof Helt
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Jean Delvare
     
  • With multihead support always enabled, these macros are no longer needed
    and make the code harder to read.

    Signed-off-by: Jean Delvare
    Acked-by: Petr Vandrovec
    Cc: Krzysztof Helt
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Jean Delvare
     
  • With multihead support always enabled, these macros are no longer needed
    and make the code harder to read.

    Signed-off-by: Jean Delvare
    Acked-by: Petr Vandrovec
    Cc: Krzysztof Helt
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Jean Delvare
     
  • I would like to get rid of option CONFIG_FB_MATROX_MULTIHEAD and just
    always enable it. There are many reasons for doing this:

    * CONFIG_FB_MATROX_MULTIHEAD=y is what all x86 distributions do, so it
    definitely works or we would know by now.

    * Building the matroxfb driver with CONFIG_FB_MATROX_MULTIHEAD not set
    results in the following build warning:

    drivers/video/matrox/matroxfb_crtc2.c: In function 'matroxfb_dh_open':
    drivers/video/matrox/matroxfb_crtc2.c:265: warning: the address of 'matroxfb_global_mxinfo' will always evaluate as 'true'
    drivers/video/matrox/matroxfb_crtc2.c: In function 'matroxfb_dh_release':
    drivers/video/matrox/matroxfb_crtc2.c:285: warning: the address of 'matroxfb_global_mxinfo' will always evaluate as 'true'

    This is nothing to be worried about, the driver will work fine, but build
    warnings are still annoying.

    * The trick to get multihead support without CONFIG_FB_MATROX_MULTIHEAD,
    which is described in the config help text, no longer works: you can't
    load the same kernel module more than once.

    * I fail to see how CONFIG_FB_MATROX_MULTIHEAD=y would make the code
    significantly slower, contrary to what the help text says. A few extra
    parameters on the stack here and there can't really slow things down in
    comaprison to the rest of the code, and register access.

    * The driver built without CONFIG_FB_MATROX_MULTIHEAD is larger than the
    driver build with CONFIG_FB_MATROX_MULTIHEAD=y by 8%.

    * One less configuration option makes things simpler. We add options
    all the time, being able to remove one for once is nice. It improves
    testing coverage. And I don't think the Matrox adapters are still
    popular enough to warrant overdetailed configuration settings.

    * We should be able to unobfuscate the driver code quite a bit after
    this change (patches follow.)

    Signed-off-by: Jean Delvare
    Acked-by: Petr Vandrovec
    Cc: Krzysztof Helt
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Jean Delvare
     

09 Jul, 2009

4 commits


07 Jul, 2009

1 commit

  • This way they'll be properly initialized early enough for users that may
    touch them before the framebuffer has been registered.

    Drivers that allocate their fb_info structure some other way (like
    matrocfb's broken static allocation) need to be fixed up appropriately.

    Signed-off-by: Paul Mundt
    Signed-off-by: Linus Torvalds

    Paul Mundt
     

01 Jul, 2009

1 commit

  • Add a mutex to avoid a circular locking problem between the mm layer
    semaphore and fbdev ioctl mutex through the fb_mmap() call.

    Also, add mutex to all places where smem_start and smem_len fields change
    so the mutex inside the fb_mmap() is actually used. Changing of these
    fields before calling the framebuffer_register() are not mutexed.

    This is 2.6.31 material. It removes one lockdep (fb_mmap() and
    register_framebuffer()) but there is still another one (fb_release() and
    register_framebuffer()). It also cleans up handling of the smem_start and
    smem_len fields used by mutexed section of the fb_mmap().

    Signed-off-by: Krzysztof Helt
    Cc: Peter Zijlstra
    Cc: "Rafael J. Wysocki"
    Cc:
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Krzysztof Helt
     

17 Oct, 2008

1 commit

  • Support the Matrox G200eV chip, based on timings that I found in the X.org
    matrox driver.

    Signed-off-by: Darrick J. Wong
    Acked-by: Krzysztof Helt
    Cc: Petr Vandrovec
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Darrick J. Wong
     

13 Aug, 2008

3 commits

  • The legacy i2c model is going away soon, so switch to the new model.

    Signed-off-by: Jean Delvare
    Acked-by: Krzysztof Helt
    Cc: Petr Vandrovec
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Jean Delvare
     
  • Clean up the use of structure templates in i2c-matroxfb. In this case
    it's more efficient to initialize the few fields we need individually.
    This makes i2c-matroxfb.ko 16% smaller on my system.

    Signed-off-by: Jean Delvare
    Acked-by: Krzysztof Helt
    Cc: Petr Vandrovec
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Jean Delvare
     
  • I broke an error path with d03c21ec0be7787ff6b75dcf56c0e96209ccbfbd,
    sorry about that.

    The machine will crash if the i2c_attach_client() or maven_init_client()
    calls fail, although nobody has yet reported this happening.

    Signed-off-by: Jean Delvare
    Acked-by: Krzysztof Helt
    Cc: Petr Vandrovec
    Cc: [2.6.25.x, 2.6.26.x]
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Jean Delvare
     

02 Aug, 2008

1 commit

  • Some module parameters with only one line have the '\n' at the end of the
    description. This is not needed nor wanted as after the description the
    type (i.e. int) is followed by a newline.

    Some modules contain a multi-line description, these are not affected
    by this patch.

    Signed-off-by: Niels de Vos
    Acked-by: Randy Dunlap
    Cc: John W. Linville
    Cc: Ed L. Cashin
    Cc: Dave Airlie
    Cc: Roland Dreier
    Acked-by: Mauro Carvalho Chehab
    Cc: Jeff Garzik
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Niels de Vos
     

15 Jul, 2008

1 commit


23 May, 2008

1 commit

  • drivers/video/aty/atyfb_base.c:3359:26: warning: Using plain integer as NULL pointer
    drivers/video/aty/radeon_base.c:2280:32: warning: Using plain integer as NULL pointer
    drivers/video/matrox/matroxfb_base.h:203:25: warning: Using plain integer as NULL pointer
    drivers/video/matrox/matroxfb_base.h:203:25: warning: Using plain integer as NULL pointer
    drivers/video/sis/sis_main.c:5790:44: warning: Using plain integer as NULL pointer

    Signed-off-by: Harvey Harrison
    Signed-off-by: Linus Torvalds

    Harvey Harrison
     

29 Apr, 2008

1 commit


28 Apr, 2008

1 commit

  • __FUNCTION__ is gcc-specific, use __func__

    Signed-off-by: Harvey Harrison
    Cc: "Antonino A. Daplas"
    Cc: Krzysztof Helt
    Cc: Antonino Daplas
    Cc: Antonino A. Daplas
    Cc: Antonino Daplas
    Cc: Richard Purdie
    Cc: Jean Delvare
    Cc: Adrian Bunk
    Cc: Russell King
    Cc: Benjamin Herrenschmidt
    Cc: Ben Dooks
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Harvey Harrison
     

28 Jan, 2008

1 commit


17 Oct, 2007

1 commit


12 Aug, 2007

1 commit

  • This builds upon my previous attempts to resolve some jitter problems seen
    with the Matrox G450 and G550 -based cards, including odd disparities observed
    between x86 and Power -based machines in a somewhat less hackish way (removing
    the hacked ifdefs).

    Apparently, preference should be given to use the DVI PLL when frequencies
    permit, the Standard PLL otherwise. The max pixel clock for the panellink
    interface is extracted from the PInS information on the card and used as a
    limit to determine which PLL to use.

    Signed-off-by: Paul A. Clarke
    Acked-by: Petr Vandrovec
    Signed-off-by: Antonino Daplas
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Paul A. Clarke
     

18 Jul, 2007

3 commits


13 Jul, 2007

1 commit

  • * master.kernel.org:/pub/scm/linux/kernel/git/gregkh/pci-2.6: (34 commits)
    PCI: Only build PCI syscalls on architectures that want them
    PCI: limit pci_get_bus_and_slot to domain 0
    PCI: hotplug: acpiphp: avoid acpiphp "cannot get bridge info" PCI hotplug failure
    PCI: hotplug: acpiphp: remove hot plug parameter write to PCI host bridge
    PCI: hotplug: acpiphp: fix slot poweroff problem on systems without _PS3
    PCI: hotplug: pciehp: wait for 1 second after power off slot
    PCI: pci_set_power_state(): check for PM capabilities earlier
    PCI: cpci_hotplug: Convert to use the kthread API
    PCI: add pci_try_set_mwi
    PCI: pcie: remove SPIN_LOCK_UNLOCKED
    PCI: ROUND_UP macro cleanup in drivers/pci
    PCI: remove pci_dac_dma_... APIs
    PCI: pci-x-pci-express-read-control-interfaces cleanups
    PCI: Fix typo in include/linux/pci.h
    PCI: pci_ids, remove double or more empty lines
    PCI: pci_ids, add atheros and 3com_2 vendors
    PCI: pci_ids, reorder some entries
    PCI: i386: traps, change VENDOR to DEVICE
    PCI: ATM: lanai, change VENDOR to DEVICE
    PCI: Change all drivers to use pci_device->revision
    ...

    Linus Torvalds
     

12 Jul, 2007

1 commit