Eric Lee / smarc-fsl-linux-kernel

17 Oct, 2007

1 commit

09 Dec, 2006

1 commit

  • adf6b2065   [PATCH] fbcmap.c: mark structs const or __read_mostly ... Browse Code »

    - Mark the default colormaps read-only, as nobody should be allowed to
    modify them

    - Additionally mark color values as __read_mostly since they will only be
    modified (very seldom) by fb_invert_cmaps()

    - Add named C99-initializers in fb_cmap structs and use the ARRAY_SIZE()
    macro

    Signed-off-by: Helge Deller
    Acked-by: James Simmons
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Helge Deller
     

11 Jul, 2006

1 commit

  • a8f340e39   [PATCH] vt: Remove VT-specific declarations and definitions from tty.h ... Browse Code »

    MAX_NR_CONSOLES, fg_console, want_console and last_console are more of a
    function of the VT layer than the TTY one. Moving these to vt.h and vt_kern.h
    allows all of the framebuffer and VT console drivers to remove their
    dependency on tty.h.

    [akpm@osdl.org: fix alpha build]
    Signed-off-by: Jon Smirl
    Signed-off-by: Antonino Daplas
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Jon Smirl
     

28 Mar, 2006

1 commit

  • db77ec270   [PATCH] framebuffer: cmap-setting return values ... Browse Code »

    A set of 3 small bugfixes, all of which are related to bogus return values
    of fb colormap-setting functions.

    First, fb_alloc_cmap returns -1 if memory allocation fails. This is a hard
    condition to reproduce since you'd have to be really low on memory, but from
    studying the contexts in which it is called, I think this function should be
    returning a negative errno, and the -1 will be seen as an EPERM. Switching it
    to -ENOMEM makes sense.

    Second, the store_cmap function which is called for writes to
    /sys/class/graphics/fb0/color_map returns 0 for success, but it should be
    returning the count of bytes written since its return value ends up in
    userspace as the result of the write() syscall.

    Third, radeonfb returns 1 instead of a negative errno when FBIOPUTCMAP is
    called with an oversized colormap. This is seen in userspace as a return
    value of 1 from the ioctl() syscall with errno left unchanged. A more
    useful return value would be -EINVAL.

    Signed-off-by: Alan Curry
    Cc: "Antonino A. Daplas"
    Cc: Benjamin Herrenschmidt
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Alan Curry
     

28 Jul, 2005

1 commit

  • 03e259a9c   [PATCH] fbdev: update info->cmap when setting cmap from user-/kernelspace. ... Browse Code »

    The fb_info struct, as defined in include/linux/fb.h, contains an element
    that is supposed to hold the current color map:
    struct fb_cmap cmap; /* Current cmap */

    This cmap is currently never updated when either fb_set_cmap() or
    fb_set_user_cmap() are called. As a result, info->cmap contains the
    default cmap that was set by a device driver/fbcon and a userspace
    application using the FBIOGETCMAP ioctl will not always get the *currently*
    used color map.

    The patch fixes this by making sure the cmap is copied to info->cmap after
    it is set correctly. It moves most of the code that is responsible for
    setting the cmap to fb_set_cmap() and out of fb_set_user_cmap() to avoid
    code-duplication.

    Signed-off-by: Michal Januszewski
    Cc:
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Michal Januszewski
     

01 May, 2005

1 commit

  • 714943766   [PATCH] fbdev: Batch cmap changes at driver level ... Browse Code »

    This patch adds to the fbdev interface a set_cmap callback that allow the
    driver to "batch" palette changes. This is useful for drivers like
    radeonfb which might require lenghtly workarounds on palette accesses, thus
    allowing to factor out those workarounds efficiently.

    Signed-off-by: Benjamin Herrenschmidt
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Benjamin Herrenschmidt
     

17 Apr, 2005

1 commit

  • 1da177e4c   Linux-2.6.12-rc2 ... Browse Code »

    Initial git repository build. I'm not bothering with the full history,
    even though we have it. We can create a separate "historical" git
    archive of that later if we want to, and in the meantime it's about
    3.2GB when imported into git - space that would just make the early
    git days unnecessarily complicated, when we don't have a lot of good
    infrastructure for it.

    Let it rip!

    Linus Torvalds