Eric Lee / smarc-fsl-linux-kernel

25 Jul, 2011

1 commit

  • 04fee895e   DRM: clean up and document parsing of video= parameter ... Browse Code »

    The video= parameter of the DRM drivers supports some additional flags that
    the normal fb drivers do not have. They also allow to limit these flags to
    specific outputs. Both things were previously undocumented.

    Also the parsing of the line had some oddities:
    -A lot of misplaced options were silently ignored or partly rejected instead
    of stopping the parsing immediately
    -The 'R' option is documented to follow the 'M' option if specified. It is not
    documented that 'M' is needed to specify 'R' (also this is the case for normal
    fb drivers). In fact the code is correct for normal fb drivers but wrong for
    DRM ones.
    The old code allowed 'R' only _before_ 'M' (since it parses backwards) and only
    if 'M' is given at all which is not needed for the DRM drivers.
    -the margins option ('m') was parsed but later ignored even if the later
    functions support it.
    -specifying multiple enable options at the same time did not lead to an error.
    -specifying something bogus for horizontal resolution (i.e. other things as
    digits) did not lead to an error but an invalid resolution was used.

    If any errors are encountered the position of the faulting string is now
    printed to the user and the complete mode is ignored. This gives much
    more consistent error behaviour.

    I also removed some useless assignments and changed the local flag variables
    to be bool.

    Signed-off-by: Rolf Eike Beer
    Signed-off-by: Dave Airlie

    Rolf Eike Beer
     

28 Apr, 2008

1 commit

10 Sep, 2005

1 commit

  • 96fe6a210   [PATCH] fbdev: Add VESA Coordinated Video Timings (CVT) support ... Browse Code »

    The Coordinated Video Timings (CVT) is the latest standard approved by VESA
    concerning video timings generation. It addresses the limitation of GTF which
    is designed mainly for CRT displays. CRT's have a high blanking requirement
    (as much as 25% of the horizontal frame length) which artificially increases
    the pixelclock. Digital displays, on the other hand, needs to conserve the
    pixelclock as much as possible. The GTF also does not take into account the
    different aspect ratios in its calculation.

    The new function added is fb_find_mode_cvt(). It is called by fb_find_mode()
    if it recognizes a mode option string formatted for CVT. The format is:

    x[M][R][-][][i][m]

    The 'M' tells the function to calculate using CVT. On it's own, it will
    compute a timing for CRT displays at 60Hz. If the 'R' is specified, 'reduced
    blanking' computation will be used, best for flatpanels. The 'i' and the 'm'
    is for 'interlaced mode' and 'with margins' respectively.

    To determine if CVT was used, check for dmesg for something like this:

    CVT Mode - M[-R], ie: .480M3-R (800x600 reduced blanking)

    where: pix - product of xres and yres, in MB
    M - is a CVT mode
    n - the aspect ratio (3 - 4:3; 4 - 5:4; 9 - 16:9, 15:9; A - 16:10)
    -R - reduced blanking

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

    Antonino A. Daplas
     

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