Eric Lee / smarc-fsl-linux-kernel

01 Jul, 2006

1 commit

12 Mar, 2006

1 commit

10 Nov, 2005

1 commit

07 Nov, 2005

1 commit

  • c465e05a0   [PATCH] fbcon/fbdev: Move softcursor out of fbdev to fbcon ... Browse Code »

    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

  • 9480e307c   [PATCH] DRIVER MODEL: Get rid of the obsolete tri-level suspend/resume callbacks ... Browse Code »

    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
     

05 Sep, 2005

1 commit

08 Jul, 2005

1 commit

  • 316240f66   [PATCH] m32r: framebuffer device support ... Browse Code »

    This patch is for supporting Epson s1d13xxx framebuffer device for m32r. #
    Sorry, a little bigger.

    The Epson s1d13806 is already supported by 2.6.12 kernel, and its driver is
    placed as drivers/video/s1d13xxxfb.c.

    For the m32r, a header file include/asm-m32r/s1d13806.h was prepared for
    several m32r target platforms. It was originally generated by an Epson
    tool S1D13806CFG.EXE, and modified manually for the m32r platforms.

    Signed-off-by: Hayato Fujiwara
    Signed-off-by: Hirokazu Takata
    Cc: "Antonino A. Daplas"
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Hirokazu Takata
     

22 Jun, 2005

1 commit

  • 27f931dac   [PATCH] s1d13xxxfb linkage fix ... Browse Code »

    s1d13xxxfb_remove() is referenced from s1d13xxxfb_probe(), which is marked
    __devinit(). So s1d13xxxfb_remove() cannot be marked __devexit.

    Does this all make sense? Clearly the __devexit section will still be in
    core when the __devinit code is run, if the driver was loaded as a module.

    But I suppose that if the driver is statically linked, the __devexit section
    might be dropped early in boot. Still, we wouldn't drop __devexit prior to
    initcall completion, at which point the __devinit code has all been run
    anyway.

    verdict: this code was legal and made sense. Is this a generic problem, or an
    arm-specific problem?

    UPD include/linux/compile.h
    CC init/version.o
    LD init/built-in.o
    LD .tmp_vmlinux1
    `.exit.text' referenced in section `.init.text' of drivers/built-in.o: defined in discarded section `.exit.text' of drivers/built-in.o

    Cc: Russell King
    Cc: Rusty Russell
    Cc: Greg KH
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Andrew Morton
     

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