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
     

04 Jul, 2013

1 commit


30 May, 2012

1 commit

  • This patchset adds early fb blank feature that a callback of lcd panel
    driver is called prior to specific fb driver's one. In the case of
    MIPI-DSI based video mode LCD Panel, for lcd power off, the power off
    commands should be transferred to lcd panel with display and mipi-dsi
    controller enabled because the commands is set to lcd panel at vsync porch
    period. and in opposite case, the callback of fb driver should be called
    prior to lcd panel driver's one because of same issue. Also if fb_blank
    mode is changed to FB_BLANK_POWERDOWN then display controller would be
    off(clock disable) but lcd panel would be still on. at this time, you
    could see some issue like sparkling on lcd panel because video clock to be
    delivered to ldi module of lcd panel was disabled. this issue could
    occurs for all lcd panels.

    The callback order is as the following:

    at fb_blank function of fbmem.c
    -> fb_notifier_call_chain(FB_EARLY_EVENT_BLANK)
    -> lcd panel driver's early_set_power()
    -> info->fbops->fb_blank()
    -> spcefic fb driver's fb_blank()
    -> fb_notifier_call_chain(FB_EVENT_BLANK)
    -> lcd panel driver's set_power()
    -> fb_notifier_call_chain(FB_R_EARLY_EVENT_BLANK) if
    info->fops->fb_blank() was failed.

    fb_notifier_call_chain(FB_R_EARLY_EVENT_BLANK) would be called to revert
    the effects of previous FB_EARLY_EVENT_BLANK call. and note that if
    early_set_power() of lcd_ops is NULL then early fb blank callback would be
    ignored.

    This patch:

    Add early_set_power and r_early_set_power callbacks. early_set_power
    callback is called prior to fb_blank() of fbmem.c and r_early_set_power
    callback is called if fb_blank() was failed to revert the effects of the
    early_set_power call of lcd panel driver.

    Signed-off-by: Inki Dae
    Signed-off-by: Kyungmin Park
    Cc: Lars-Peter Clausen
    Cc: Florian Tobias Schandinat
    Cc: Richard Purdie
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Inki Dae
     

27 May, 2010

1 commit

  • This is S6E63M0 AMOLED LCD Panel(480x800) driver using 3-wired SPI
    interface also almost features for lcd panel driver has been implemented
    in here. and I added new structure common for all the lcd panel drivers
    to include/linux/lcd.h file.

    LCD Panel driver needs interfaces for controlling device power such as
    power on/off and reset. these interfaces are device specific so it should
    be implemented to machine code at this time, we should create new
    structure for registering these functions as callbacks and also a header
    file for that structure and finally registered callback functions would be
    called by lcd panel driver. such header file(including new structure for
    lcd panel) would be added for all the lcd panel drivers.

    If anyone provides common structure for registering such callback
    functions then we could reduce unnecessary header files for lcd panel. I
    thought that suitable anyone could be include/linux/lcd.h so a new
    lcd_platform_data structure was added there.

    [akpm@linux-foundation.org: coding-style fixes]
    [randy.dunlap@oracle.com: fix s6e63m0 kconfig]
    [randy.dunlap@oracle.com: fix device attribute functions return types]
    Signed-off-by: InKi Dae
    Reviewed-by: KyungMin Park
    Signed-off-by: Randy Dunlap
    Signed-off-by: Andrew Morton
    Signed-off-by: Richard Purdie

    InKi Dae
     

24 Sep, 2008

1 commit


25 Jul, 2008

1 commit

  • Add the lcd_device being checked to the check_fb entry of lcd_ops. This
    ensures that any driver using this to check against it's own state can do
    so, and also makes all the calls in lcd_ops more orthogonal in their
    arguments.

    Signed-off-by: Ben Dooks
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Ben Dooks
     

16 Jul, 2007

1 commit

  • Convert the backlight and LCD classes from struct class_device
    to struct device since class_device is scheduled for removal.

    One nasty API break is the backlight power attribute has had to be
    renamed to bl_power and the LCD power attribute has had to be renamed
    to lcd_power since the original names clash with the core. I can't see
    a way around this.

    Signed-off-by: Richard Purdie
    Acked-by: Greg Kroah-Hartman

    Richard Purdie
     

20 Feb, 2007

4 commits

  • Per device data such as brightness belongs to the indivdual device
    and should therefore be separate from the the backlight operation
    function pointers. This patch splits the two types of data and
    allows simplifcation of some code.

    Signed-off-by: Richard Purdie

    Richard Purdie
     
  • Convert internal semaphore to a mutex

    Signed-off-by: Richard Purdie

    Richard Purdie
     
  • backlight_device->sem has a very specific use as documented in the
    header file. The external users of this are using it for a different
    reason, to serialise access to the update_status() method.

    backlight users were supposed to implement their own internal
    serialisation of update_status() if needed but everyone is doing
    things differently and incorrectly. Therefore add a global mutex to
    take care of serialisation for everyone, once and for all.

    Locking for get_brightness remains optional since most users don't
    need it.

    Also update the lcd class in a similar way.

    Signed-off-by: Richard Purdie

    Richard Purdie
     
  • Remove uneeded owner field from backlight_properties structure.

    Nothing uses it and it is unlikely that it will ever be used. The
    backlight class uses other means to ensure that nothing references
    unloaded code.

    Based on a patch from Dmitry Torokhov

    Signed-off-by: Richard Purdie

    Richard Purdie
     

17 Apr, 2005

1 commit

  • 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