02 Jun, 2011

1 commit

  • Reorder the labels at the end of the function to correspond to the order in
    which the resources are allocated.

    A simplified version of the semantic match that finds this problem is as
    follows: (http://coccinelle.lip6.fr/)

    //
    @r exists@
    expression e1,e2;
    statement S;
    @@

    e1 = clk_get@p1(...);
    ... when != e1 = e2
    when != clk_put(e1)
    when any
    if (...) { ... when != clk_put(e1)
    when != if (...) { ... clk_put(e1) ... }
    * return@p3 ...;
    } else S
    //

    Signed-off-by: Julia Lawall
    Acked-by: Sascha Hauer
    Signed-off-by: Paul Mundt

    Julia Lawall
     

19 May, 2011

1 commit

  • remove usage of CONFIG_ARCH_MX1. It's mostly unused anyway, replace
    it with cpu_is_mx1() where necessary. Also, depend on
    IMX_HAVE_PLATFORM_IMX_FB instead of the architectures directly.

    LAKML-Reference: 20110303141244.GQ29521@pengutronix.de
    Acked-by: Paul Mundt
    Signed-off-by: Uwe Kleine-König
    Signed-off-by: Sascha Hauer

    Sascha Hauer
     

23 Mar, 2011

1 commit

  • There may be multiple ways of controlling the backlight on a given
    machine. Allow drivers to expose the type of interface they are
    providing, making it possible for userspace to make appropriate policy
    decisions.

    Signed-off-by: Matthew Garrett
    Cc: Richard Purdie
    Cc: Chris Wilson
    Cc: David Airlie
    Cc: Alex Deucher
    Cc: Ben Skeggs
    Cc: Zhang Rui
    Cc: Len Brown
    Cc: Jesse Barnes
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Matthew Garrett
     

12 Jan, 2011

1 commit


27 Dec, 2010

1 commit


11 Aug, 2010

1 commit

  • From: Eric Bénard

    This fixes the following build failure:

    drivers/built-in.o: In function `imxfb_probe': mxcmmc.c:(.init.text+0xd04): undefined reference to `backlight_device_register'
    drivers/built-in.o: In function `imxfb_remove': mxcmmc.c:(.devexit.text+0x44): undefined reference to `backlight_device_unregister'

    that was introduced by

    7a2bb23 (imxfb: add pwmr controlled backlight support)

    Signed-off-by: Eric Bénard
    Signed-off-by: Uwe Kleine-König
    Signed-off-by: Russell King

    Eric Bénard
     

26 Jul, 2010

1 commit


03 Feb, 2010

1 commit

  • The probe function passes a pointer to a struct fb_info to
    platform_set_drvdata(), so don't interpret the return value of
    platform_get_drvdata() as a pointer to struct imxfb_info.

    The original imxfb_info *fbi backlight_power was NULL but in imxfb_suspend
    it was 4 resulting in an oops as imxfb_suspend calls
    imxfb_disable_controller(fbi) which in turn has

    if (fbi->backlight_power)
    fbi->backlight_power(0);

    Signed-off-by: Uwe Kleine-König
    Acked-by: Sascha Hauer
    Cc:
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Uwe Kleine-König
     

21 Sep, 2009

1 commit


07 Aug, 2009

3 commits


27 Mar, 2009

2 commits


13 Mar, 2009

4 commits


16 Dec, 2008

7 commits


07 Aug, 2008

2 commits


25 Jul, 2008

1 commit

  • On 32-bit architectures PAGE_ALIGN() truncates 64-bit values to the 32-bit
    boundary. For example:

    u64 val = PAGE_ALIGN(size);

    always returns a value < 4GB even if size is greater than 4GB.

    The problem resides in PAGE_MASK definition (from include/asm-x86/page.h for
    example):

    #define PAGE_SHIFT 12
    #define PAGE_SIZE (_AC(1,UL) << PAGE_SHIFT)
    #define PAGE_MASK (~(PAGE_SIZE-1))
    ...
    #define PAGE_ALIGN(addr) (((addr)+PAGE_SIZE-1)&PAGE_MASK)

    The "~" is performed on a 32-bit value, so everything in "and" with
    PAGE_MASK greater than 4GB will be truncated to the 32-bit boundary.
    Using the ALIGN() macro seems to be the right way, because it uses
    typeof(addr) for the mask.

    Also move the PAGE_ALIGN() definitions out of include/asm-*/page.h in
    include/linux/mm.h.

    See also lkml discussion: http://lkml.org/lkml/2008/6/11/237

    [akpm@linux-foundation.org: fix drivers/media/video/uvc/uvc_queue.c]
    [akpm@linux-foundation.org: fix v850]
    [akpm@linux-foundation.org: fix powerpc]
    [akpm@linux-foundation.org: fix arm]
    [akpm@linux-foundation.org: fix mips]
    [akpm@linux-foundation.org: fix drivers/media/video/pvrusb2/pvrusb2-dvb.c]
    [akpm@linux-foundation.org: fix drivers/mtd/maps/uclinux.c]
    [akpm@linux-foundation.org: fix powerpc]
    Signed-off-by: Andrea Righi
    Cc:
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Andrea Righi
     

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
     

17 Oct, 2007

2 commits

  • The i.MX frame-buffer read operation should be faster for all configurations
    then drawing each individual character again in response to scroll events.

    The nonstandard fields allows to configure frame-buffer special options flags
    for different display configurations by board specific initialization code.

    One of such specific options is reversed order of pixels in each individual
    byte. i.MX frame-buffer seems to be designed for big-endian use first. The
    byte order is correctly configured for little-endian ordering, but if 1, 2 or
    4 bits per pixel are used, pixels ordering is incompatible to Linux generic
    frame-buffer drawing functions.

    The patch "Allow generic BitBLT functions to work with swapped pixel order in
    bytes" introduces required functionality into FBDEV core. The pixels ordering
    selection has to be enabled at compile time CONFIG_FB_CFB_REV_PIXELS_IN_BYTE
    and for each display configuration which requires it by flag
    FB_NONSTD_REV_PIX_IN_B in "nonstd" field of info structure.

    This patch provides way for board specific code to select this option.

    Signed-off-by: Pavel Pisa
    Signed-off-by: Antonino Daplas
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Pavel Pisa
     
  • This patch replaces with after the
    checkpatch.pl hint. The include of is removed if the driver
    does not use it.

    Signed-off-by: Krzysztof Helt
    Signed-off-by: Antonino Daplas
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Krzysztof Helt
     

24 May, 2007

2 commits

  • info->pseudo_palette was previously kmalloced. Do not overwrite it afterwards

    Signed-off-by: Sascha Hauer
    Signed-off-by: Antonino Daplas
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Sascha Hauer
     
  • Here are some small fixes for the imxfb framebuffer driver:

    - remove ifndef for MX1FS2 platform which is not present in the kernel.
    - REV, CLS, PS and SPL_SPR are only needed with some sharp displays.
    Only setup the corresponding io pins when such a display is connected.

    Signed-off-by: Sascha Hauer
    Signed-off-by: Antonino Daplas
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Sascha Hauer
     

15 Feb, 2007

1 commit

  • After Al Viro (finally) succeeded in removing the sched.h #include in module.h
    recently, it makes sense again to remove other superfluous sched.h includes.
    There are quite a lot of files which include it but don't actually need
    anything defined in there. Presumably these includes were once needed for
    macros that used to live in sched.h, but moved to other header files in the
    course of cleaning it up.

    To ease the pain, this time I did not fiddle with any header files and only
    removed #includes from .c-files, which tend to cause less trouble.

    Compile tested against 2.6.20-rc2 and 2.6.20-rc2-mm2 (with offsets) on alpha,
    arm, i386, ia64, mips, powerpc, and x86_64 with allnoconfig, defconfig,
    allmodconfig, and allyesconfig as well as a few randconfigs on x86_64 and all
    configs in arch/arm/configs on arm. I also checked that no new warnings were
    introduced by the patch (actually, some warnings are removed that were emitted
    by unnecessarily included header files).

    Signed-off-by: Tim Schmielau
    Acked-by: Russell King
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Tim Schmielau
     

01 Jul, 2006

1 commit


07 Jan, 2006

1 commit


10 Nov, 2005

1 commit


07 Nov, 2005

1 commit

  • According to Jon Smirl, filling in the field fb_cursor with soft_cursor for
    drivers that do not support hardware cursors is redundant. The soft_cursor
    function is usable by all drivers because it is just a wrapper around
    fb_imageblit. And because soft_cursor is an fbcon-specific hook, the file is
    moved to the console directory.

    Thus, drivers that do not support hardware cursors can leave the fb_cursor
    field blank. For drivers that do, they can fill up this field with their own
    version.

    The end result is a smaller code size. And if the framebuffer console is not
    loaded, module/kernel size is also reduced because the soft_cursor module will
    also not be loaded.

    Signed-off-by: Antonino Daplas
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Antonino A. Daplas
     

30 Oct, 2005

1 commit


29 Oct, 2005

1 commit

  • In PM v1, all devices were called at SUSPEND_DISABLE level. Then
    all devices were called at SUSPEND_SAVE_STATE level, and finally
    SUSPEND_POWER_DOWN level. However, with PM v2, to maintain
    compatibility for platform devices, I arranged for the PM v2
    suspend/resume callbacks to call the old PM v1 suspend/resume
    callbacks three times with each level in order so that existing
    drivers continued to work.

    Since this is obsolete infrastructure which is no longer necessary,
    we can remove it. Here's an (untested) patch to do exactly that.

    Signed-off-by: Russell King
    Signed-off-by: Greg Kroah-Hartman

    Russell King