02 Nov, 2017

1 commit

  • Many source files in the tree are missing licensing information, which
    makes it harder for compliance tools to determine the correct license.

    By default all files without license information are under the default
    license of the kernel, which is GPL version 2.

    Update the files which contain no license information with the 'GPL-2.0'
    SPDX license identifier. The SPDX identifier is a legally binding
    shorthand, which can be used instead of the full boiler plate text.

    This patch is based on work done by Thomas Gleixner and Kate Stewart and
    Philippe Ombredanne.

    How this work was done:

    Patches were generated and checked against linux-4.14-rc6 for a subset of
    the use cases:
    - file had no licensing information it it.
    - file was a */uapi/* one with no licensing information in it,
    - file was a */uapi/* one with existing licensing information,

    Further patches will be generated in subsequent months to fix up cases
    where non-standard license headers were used, and references to license
    had to be inferred by heuristics based on keywords.

    The analysis to determine which SPDX License Identifier to be applied to
    a file was done in a spreadsheet of side by side results from of the
    output of two independent scanners (ScanCode & Windriver) producing SPDX
    tag:value files created by Philippe Ombredanne. Philippe prepared the
    base worksheet, and did an initial spot review of a few 1000 files.

    The 4.13 kernel was the starting point of the analysis with 60,537 files
    assessed. Kate Stewart did a file by file comparison of the scanner
    results in the spreadsheet to determine which SPDX license identifier(s)
    to be applied to the file. She confirmed any determination that was not
    immediately clear with lawyers working with the Linux Foundation.

    Criteria used to select files for SPDX license identifier tagging was:
    - Files considered eligible had to be source code files.
    - Make and config files were included as candidates if they contained >5
    lines of source
    - File already had some variant of a license header in it (even if
    Reviewed-by: Philippe Ombredanne
    Reviewed-by: Thomas Gleixner
    Signed-off-by: Greg Kroah-Hartman

    Greg Kroah-Hartman
     

21 Nov, 2012

1 commit


20 Jun, 2012

1 commit


13 Mar, 2012

7 commits


20 Dec, 2011

1 commit


19 Aug, 2011

1 commit


23 May, 2011

1 commit

  • Based on the patch by Takanari Hayama

    Adds support framework necessary to use Media RAM (MERAM)
    caching functionality with the LCDC. The MERAM is accessed
    through up to 4 Interconnect Buffers (ICBs).

    ICB numbers and MERAM address ranges to use are specified in
    by filling in the .meram_cfg member of the LCDC platform data

    Signed-off-by: Damian Hobson-Garcia
    Signed-off-by: Paul Mundt

    Damian
     

16 Mar, 2011

1 commit

  • Supports YCbCr420sp, YCbCr422sp, and YCbCr44sp, formats
    (bpp = 12, 16, and 24) respectively.

    When double-buffering both Y planes appear before the C planes (Y-Y-C-C),
    as opposed to Y-C-Y-C.

    Set .nonstd in struct sh_mobile_lcdc_chan_cfg to enable YUV mode, and use
    .bpp to distiguish between the 3 modes.
    The value of .nonstd is copied to bits 16-31 of LDDFR in the LCDC and
    should be set accordingly.
    .nonstd must be set to 0 for RGB mode.

    Due to the encoding of YUV data, the framebuffer will clear to green
    instead of black.

    In YUV 420 mode, panning is only possible in 2 line increments.
    Additionally in YUV 420 mode the vertical resolution of the framebuffer
    must be an even number.

    Signed-off-by: Damian Hobson-Garcia
    Signed-off-by: Paul Mundt

    Damian Hobson-Garcia
     

10 Mar, 2011

1 commit


14 Sep, 2010

2 commits

  • The SH-Mobile HDMI driver runs in several contexts: ISR, delayed work-queue,
    task context, when called from the sh_mobile_lcdc framebuffer driver. This
    creates ample race possibilities. Even though most these races are purely
    theoretical, it is better to close them. To trace fb_info validity we install a
    notification callback in the HDMI driver, and the only way for it to get to
    driver internal data is by using struct sh_mobile_lcdc_chan, therefore it had
    to be extracted into a separate common header.

    Signed-off-by: Guennadi Liakhovetski
    Signed-off-by: Paul Mundt

    Guennadi Liakhovetski
     
  • This is a preparation for HDMI hotplug support. This patch just moves all
    platform defined video modes for the sh_mobile_lcdcfb driver to separate
    arrays and switches all users to use element 0 of that array, so, this patch
    doesn't introduce any functional changes and as such should not cause any
    regressions.

    Signed-off-by: Guennadi Liakhovetski
    Signed-off-by: Paul Mundt

    Guennadi Liakhovetski
     

04 Aug, 2010

1 commit


31 May, 2010

1 commit


25 May, 2010

1 commit

  • FBIO_WAITFORVSYNC is currently implemented by matroxfb, atyfb, intelfb and
    more. All of them keep redefining the same FBIO_WAITFORVSYNC macro over
    and over again, so move it to linux/fb.h and clean up those duplicate
    defines.

    Signed-off-by: Grazvydas Ignotas
    Cc: Ville Syrjala
    Cc: Grant Likely
    Cc: Maik Broemme
    Cc: Petr Vandrovec
    Cc: Benjamin Herrenschmidt
    Cc: Krzysztof Helt
    Cc: "Hiremath, Vaibhav"
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Grazvydas Ignotas
     

24 May, 2010

1 commit


16 Feb, 2010

1 commit


09 Dec, 2009

1 commit


22 Dec, 2008

1 commit

  • This patch adds sh_mobile_lcdcfb deferred io support for SYS panels.

    The LCDC hardware block managed by the sh_mobile_lcdcfb driver supports
    RGB or SYS panel configurations. SYS panels come with an external display
    controller that is resposible for refreshing the actual LCD panel. RGB
    panels are controlled directly by the LCDC and they need to be refreshed
    by the LCDC hardware.

    In the case of SYS panels we can save some power by configuring the LCDC
    hardware block in one-shot mode. In this one-shot mode panel refresh is
    managed by software. This works well together with deferred io since it
    allows us to stop clocks for most of the time and only enable clocks when
    we actually want to trigger an update. When there is no fbdev activity
    the clocks are kept stopped which allows us to deep sleep.

    The refresh rate in deferred io mode is set using platform data. The same
    platform data can also be used to disable deferred io mode.

    As with other deferred io frame buffers user space code should use fsync()
    on the frame buffer device to trigger an update.

    Signed-off-by: Magnus Damm
    Signed-off-by: Paul Mundt

    Magnus Damm
     

20 Oct, 2008

2 commits


01 Oct, 2008

1 commit