Doug / smarc-fsl-linux-kernel

02 Apr, 2013

2 commits

  • 48a1d032c   leds: add camera LED triggers ... Browse Code »

    Some LED devices support flash/torch functionality through the LED subsystem.
    This patch enables direct LED trigger controls by the driver.
    Flash on/off and torch on/off can be done simply by other driver space.
    Two trigger APIs are added, ledtrig_flash_ctrl() and ledtrig_torch_ctrl().

    Signed-off-by: Milo(Woogyom) Kim
    Signed-off-by: Bryan Wu

    Kim, Milo
     
  • 39f7e08af   leds: trigger: use inline functions instead of macros ... Browse Code »

    Macros are used in case that an inline function doesn't work.
    Otherwise, use an empty inline function.

    (a) Case of !CONFIG_LEDS_TRIGGERS
    Following macros are replaced with inline functions.
    led_trigger_register_simple()
    led_trigger_unregister_simple()
    led_trigger_event()
    To make inline types, the structure, 'led_trigger' should be defined.
    This structure has no member at all.

    (b) Case of !CONFIG_LEDS_TRIGGER_IDE_DISK
    ledtrig_ide_activity() macro is replaced with an inline function as well.

    (c) DEFINE_LED_TRIGGER() and DEFINE_LED_TRIGGER_GLOBAL()
    Struct 'led_trigger' is defined both cases, with CONFIG_LEDS_TRIGGERS and
    without CONFIG_LEDS_TRIGGERS.
    Those macros are moved out of CONFIG_LED_TRIGGERS because of no-dependency
    on CONFIG_LEDS_TRIGGERS.

    (d) Fix build errors in mmc-core driver
    After replacing macros with inline functions, following build errors occur.
    (condition: CONFIG_LEDS_TRIGGERS is not set)

    drivers/mmc/core/core.c: In function 'mmc_request_done':
    drivers/mmc/core/core.c:164:25: error: 'struct mmc_host' has no member named 'led'
    drivers/mmc/core/core.c: In function 'mmc_start_request':
    drivers/mmc/core/core.c:254:24: error: 'struct mmc_host' has no member named 'led'
    make[3]: *** [drivers/mmc/core/core.o] Error 1

    The reason of these errors is non-existent member variable, 'led'.
    It is only valid when CONFIG_LEDS_TRIGGERS is set.
    But now, it can be used without this dependency.
    To fix build errors, member 'led' is always used without its config option in
    'include/linux/mmc/host.h'.

    Signed-off-by: Milo(Woogyom) Kim
    Signed-off-by: Bryan Wu

    Kim, Milo
     

27 Nov, 2012

2 commits

  • 057407c73   led: Add dependency on CONFIG_LEDS_TRIGGERS to led_trigger_rename_static() ... Browse Code »

    This patch fixes build warnings when CONFIG_LEDS_TRIGGERS is
    disabled as below:
    include/linux/leds.h:158:18: warning: 'struct led_trigger' declared inside parameter list [enabled by default]
    include/linux/leds.h:158:18: warning: its scope is only this definition or declaration, which is probably not what you want [enabled
    by default]

    Signed-off-by: Jingoo Han
    Acked-by: Fabio Baltieri
    Signed-off-by: Bryan Wu

    Jingoo Han
     
  • a8df7b1ab   leds: add led_trigger_rename function ... Browse Code »

    Implements a "led_trigger_rename" function to rename a trigger with
    proper locking.

    This assumes that led name was originally allocated in non-constant
    storage.

    Signed-off-by: Fabio Baltieri
    Cc: Kurt Van Dijck
    Signed-off-by: Bryan Wu

    Fabio Baltieri
     

10 Oct, 2012

1 commit

  • c7a6ced9d   Merge branch 'for-next' of git://git.kernel.org/pub/scm/linux/kernel/git/cooloney/linux-leds ... Browse Code »

    Pull LED subsystem update from Bryan Wu.

    * 'for-next' of git://git.kernel.org/pub/scm/linux/kernel/git/cooloney/linux-leds: (24 commits)
    leds: add output driver configuration for pca9633 led driver
    leds: lm3642: Use regmap_update_bits() in lm3642_chip_init()
    leds: Add new LED driver for lm3642 chips
    leds-lp5523: Fix riskiness of the page fault
    leds-lp5523: turn off the LED engines on unloading the driver
    leds-lm3530: Fix smatch warnings
    leds-lm3530: Use devm_regulator_get function
    leds: leds-gpio: adopt pinctrl support
    leds: Add new LED driver for lm355x chips
    leds-lp5523: use the i2c device id rather than fixed name
    leds-lp5523: add new device id for LP55231
    leds-lp5523: support new LP55231 device
    leds: triggers: send uevent when changing triggers
    leds-lp5523: minor code style fixes
    leds-lp5523: change the return type of lp5523_set_mode()
    leds-lp5523: set the brightness to 0 forcely on removing the driver
    leds-lp5523: add channel name in the platform data
    leds: leds-gpio: Use of_get_child_count() helper
    leds: leds-gpio: Use platform_{get,set}_drvdata
    leds: leds-gpio: use of_match_ptr()
    ...

    Linus Torvalds
     

11 Sep, 2012

1 commit

13 Aug, 2012

1 commit

  • 19e4ab54e   Merge branch 'for-arm-soc' of git://git.kernel.org/pub/scm/linux/kernel/git/cool… ... Browse Code »

    …oney/linux-leds into next/drivers

    From Bryan Wu <bryan.wu@canonical.com>:

    Based on Linus Walleij's ARM LED consolidation work, this patchset introduce a
    new generic led trigger for CPU not only for ARM but also for others.

    For enabling CPU idle event, CPU arch code should call ledtrig_cpu() stub to
    trigger idle start or idle end event.

    These patches convert old style LED driver in arch/arm to gpio_led or new led
    driver interface. Against 3.5 release and build successfully for all the machines.

    Test ledtrig-cpu driver on OMAP4 Panda board.

    v9 --> v10
    * fix compiling issue on versatile_defconfig reported by Russell King
    * rebase to 3.5 kernel and move patches to new git tree

    v8 --> v9:
    * use mutex to replace rw_sema pointed out by Tim Gardner
    * add a new struct led_trigger_cpu
    * add lock_is_inited to record mutex lock initialization

    v6 --> v7:
    * add a patch to unify the led-trigger name
    * fix some typo pointed
    * use BUG_ON to detect CPU numbers during building stage

    v5 --> v6:
    * replace __get_cpu_var() to per_cpu()
    * remove smp_processor_id() which is wrong with for_each_possible_cpu()
    * test on real OMAP4 Panda board
    * add comments about CPU hotplug in the CPU LED trigger driver

    v4 --> v5:
    * rebase all the patches on top of latest linux-next
    * replace on_each_cpu() with for_each_possible_cpu()
    * add some description of ledtrig_cpu() API
    * remove old leds code from driver nwflash.c, which should use a new led trigger then
    * this trigger driver can be built as module now

    v3 --> v4:
    * fix a typo pointed by Jochen Friedrich
    * fix some building errors
    * add Reviewed-by and Tested-by into patch log

    v2 --> v3:
    * almost rewrote the whole ledtrig-cpu driver, which is more simple
    * every CPU will have a per-CPU trigger
    * cpu trigger can be assigned to any leds
    * fix a lockdep issue in led-trigger common code
    * other fix according to review

    v1 --> v2:
    * remove select operations in Kconfig of every machines
    * add back supporting of led in core module of mach-integrator
    * solidate name scheme in ledtrig-cpu.c
    * add comments of CPU_LED_* cpu led events
    * fold patches of RealView and Versatile together
    * add machine_is_ check during assabet led driver init
    * add some Acked-by in patch logs
    * remove code for simpad machine in machine-sa11000, since Jochen Friedrich
    introduced gpiolib and gpio-led driver for simpad
    * on Assabet and Netwinder machine, LED operations is reversed like:
    setting bit means turn off leds
    clearing bit means turn on leds
    * add a new function to read CM_CTRL register for led driver

    * 'for-arm-soc' of git://git.kernel.org/pub/scm/linux/kernel/git/cooloney/linux-leds:
    ARM: use new LEDS CPU trigger stub to replace old one
    ARM: mach-sa1100: retire custom LED code
    ARM: mach-omap1: retire custom LED code
    ARM: mach-pnx4008: remove including old leds event API header file
    ARM: plat-samsung: remove including old leds event API header file
    ARM: mach-pxa: retire custom LED code
    char: nwflash: remove old led event code
    ARM: mach-footbridge: retire custom LED code
    ARM: mach-ebsa110: retire custom LED code
    ARM: mach-clps711x: retire custom LED code of P720T machine
    ARM: mach-integrator: retire custom LED code
    ARM: mach-integrator: move CM_CTRL to header file for accessing by other functions
    ARM: mach-orion5x: convert custom LED code to gpio_led and LED CPU trigger
    ARM: mach-shark: retire custom LED code
    ARM: mach-ks8695: remove leds driver, since nobody use it
    ARM: mach-realview and mach-versatile: retire custom LED code
    ARM: at91: convert old leds drivers to gpio_led and led_trigger drivers
    led-triggers: create a trigger for CPU activity

    Conflicts:
    arch/arm/mach-clps711x/p720t.c
    arch/arm/mach-sa1100/leds-cerf.c
    arch/arm/mach-sa1100/leds-lart.c

    Let's hope this is the last time we pull this and it doesn't cause
    more trouble. I have verified that version 10 causes no build
    warnings or errors any more, and the patches still look good.

    Signed-off-by: Arnd Bergmann <arnd@arndb.de>

    Arnd Bergmann
     

31 Jul, 2012

1 commit

  • 8f88731d0   led-triggers: create a trigger for CPU activity ... Browse Code »

    Attempting to consolidate the ARM LED code, this removes the
    custom RealView LED trigger code to turn LEDs on and off in
    response to CPU activity and replace it with a standard trigger.

    (bryan.wu@canonical.com:
    It introduces several syscore stubs into this trigger.
    It also provides ledtrig_cpu trigger event stub in .
    Although it was inspired by ARM work, it can be used in other arch.)

    Cc: Richard Purdie
    Signed-off-by: Linus Walleij
    Signed-off-by: Bryan Wu
    Reviewed-by: Jamie Iles
    Tested-by: Jochen Friedrich

    Bryan Wu
     

24 Jul, 2012

2 commits

  • 19cd67e2d   leds: Rename led_brightness_set() to led_set_brightness() ... Browse Code »

    Rename leds external interface led_brightness_set() to led_set_brightness().
    This is the second phase of the change to reduce confusion between the
    leds internal and external interfaces that set brightness. With this change,
    now the external interface is led_set_brightness(). The first phase renamed
    the internal interface led_set_brightness() to __led_set_brightness().
    There are no changes to the interface implementations.

    Signed-off-by: Shuah Khan
    Signed-off-by: Bryan Wu

    Shuah Khan
     
  • 5bb629c50   leds: add oneshot blink functions ... Browse Code »

    Add two new functions, led_blink_set_oneshot and
    led_trigger_blink_oneshot, to be used by triggers for one-shot blink of
    led devices.

    This is implemented extending the existing software-blink code, and uses
    the same timer and handler function.

    The behavior of the code is to do a blink-on, blink-off sequence when
    the function is called, ignoring other calls until the sequence is
    completed so that the leds keep blinking at constant rate if the
    functions are called repeatedly.

    This is meant to be used by drivers which needs to trigger on sporadic
    event, but doesn't have clear busy/idle trigger points.

    After the blink sequence the led remains off. This behavior can be
    inverted setting the "invert" argument, which blink the led off, than on
    and leave the led on after the sequence.

    (bryan.wu@canonical.com: rebase to commit 'leds: don't disable blinking
    when writing the same value to delay_on or delay_off')

    Signed-off-by: Fabio Baltieri
    Acked-by: Shuah Khan
    Signed-off-by: Bryan Wu

    Fabio Baltieri
     

30 May, 2012

1 commit

  • b00961824   leds: add new field to led_classdev struct to save activation state ... Browse Code »

    Add a new field to led_classdev to save activattion state after activate
    routine is successful. This saved state is used in deactivate routine to
    do cleanup such as removing device files, and free memory allocated during
    activation. Currently trigger_data not being null is used for this
    purpose.

    Existing triggers will need changes to use this new field.

    Signed-off-by: Shuah Khan
    Cc: Richard Purdie
    Cc: Bryan Wu
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Shuah Khan
     

25 May, 2011

1 commit

  • 4440673a9   leds: provide helper to register "leds-gpio" devices ... Browse Code »

    This function makes a deep copy of the platform data to allow it to live
    in init memory. For a kernel that supports several machines and so
    includes the definition for several leds-gpio devices this saves quite
    some memory because all but one definition can be free'd after boot.

    As the function is used by arch code it must be builtin and so cannot go
    into leds-gpio.c.

    [akpm@linux-foundation.org: s/CONFIG_LED_REGISTER_GPIO/CONFIG_LEDS_REGISTER_GPIO/]
    Signed-off-by: Uwe Kleine-König
    Cc: Russell King
    Acked-by: Richard Purdie
    Cc: Fabio Estevam
    Cc: Sascha Hauer
    Tested-by: H Hartley Sweeten
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Uwe Kleine-König
     

26 Mar, 2011

1 commit

  • 56a9ccb7b   Merge git://git.infradead.org/battery-2.6 ... Browse Code »

    * git://git.infradead.org/battery-2.6: (30 commits)
    bq20z75: Fix time and temp units
    bq20z75: Fix issues with present and suspend
    z2_battery: Fix count of properties
    s3c_adc_battery: Fix method names when PM not set
    z2_battery: Add MODULE_DEVICE_TABLE
    ds2782_battery: Add MODULE_DEVICE_TABLE
    bq20z75: Add MODULE_DEVICE_TABLE
    power_supply: Update power_supply_is_watt_property
    bq20z75: Add i2c retry mechanism
    bq20z75: Add optional battery detect gpio
    twl4030_charger: Make the driver atomic notifier safe
    bq27x00: Use single i2c_transfer call for property read
    bq27x00: Cleanup bq27x00_i2c_read
    bq27x00: Minor cleanups
    bq27x00: Give more specific reports on battery status
    bq27x00: Add MODULE_DEVICE_TABLE
    bq27x00: Add new properties
    bq27x00: Poll battery state
    bq27x00: Cache battery registers
    bq27x00: Add bq27000 support
    ...

    Linus Torvalds
     

23 Mar, 2011

1 commit

31 Jan, 2011

1 commit

12 Nov, 2010

1 commit

  • 5ada28bf7   led-class: always implement blinking ... Browse Code »

    Currently, blinking LEDs can be awkward because it is not guaranteed that
    all LEDs implement blinking. The trigger that wants it to blink then
    needs to implement its own timer solution.

    Rather than require that, add led_blink_set() API that triggers can use.
    This function will attempt to use hw blinking, but if that fails
    implements a timer for it. To stop blinking again, brightness_set() also
    needs to be wrapped into API that will stop the software blink.

    As a result of this, the timer trigger becomes a very trivial one, and
    hopefully we can finally see triggers using blinking as well because it's
    always easy to use.

    Signed-off-by: Johannes Berg
    Acked-by: Richard Purdie
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Johannes Berg
     

26 May, 2010

1 commit

  • 2146325df   leds: leds-gpio: Change blink_set callback to be able to turn off blinking ... Browse Code »

    The leds-gpio blink_set() callback follows the same prototype as the
    main leds subsystem blink_set() one.

    The problem is that to stop blink, normally, a leds driver does it
    in the brightness_set() callback when asked to set a new fixed value.

    However, with leds-gpio, the platform has no hook to do so, as this
    later callback results in a standard GPIO manipulation.

    This changes the leds-gpio specific callback to take a new argument
    that indicates whether the LED should be blinking or not and in what
    state it should be set if not. We also update the dns323 platform
    which seems to be the only user of this so far.

    Signed-off-by: Benjamin Herrenschmidt
    Signed-off-by: Richard Purdie

    Benjamin Herrenschmidt
     

24 Jun, 2009

3 commits

  • a1dd8c617   leds: Futher document blink_set ... Browse Code »

    Futher document blink_set function pointer

    Signed-off-by: Richard Purdie

    Richard Purdie
     
  • ed88bae69   leds: Add options to have GPIO LEDs start on or keep their state ... Browse Code »

    There already is a "default-on" trigger but there are problems with it.

    For one, it's a inefficient way to do it and requires led trigger support
    to be compiled in.

    But the real reason is that is produces a glitch on the LED. The GPIO is
    allocate with the LED *off*, then *later* when the trigger runs it is
    turned back on. If the LED was already on via the GPIO's reset default or
    action of the firmware, this produces a glitch where the LED goes from on
    to off to on. While normally this is fast enough that it wouldn't be
    noticeable to a human observer, there are still serious problems.

    One is that there may be something else on the GPIO line, like a hardware
    alarm or watchdog, that is fast enough to notice the glitch.

    Another is that the kernel may panic before the LED is turned back on, thus
    hanging with the LED in the wrong state. This is not just speculation, but
    actually happened to me with an embedded system that has an LED which
    should turn off when the kernel finishes booting, which was left in the
    incorrect state due to a bug in the OF LED binding code.

    We also let GPIO LEDs get their initial value from whatever the current
    state of the GPIO line is. On some systems the LEDs are put into some
    state by the firmware or hardware before Linux boots, and it is desired to
    have them keep this state which is otherwise unknown to Linux.

    This requires that the underlying GPIO driver support reading the value of
    output GPIOs. Some drivers support this and some do not.

    The platform device binding gains a field in the platform data
    "default_state" that controls this. There are three constants defined to
    select from on, off, or keeping the current state. The OpenFirmware
    binding uses a property named "default-state" that can be set to "on",
    "off", or "keep". The default if the property isn't present is off.

    Signed-off-by: Trent Piepho
    Acked-by: Grant Likely
    Acked-by: Wolfram Sang
    Acked-by: Sean MacLennan
    Signed-off-by: Richard Purdie

    Trent Piepho
     
  • 92722b1bb   leds: Further document parameters for blink_set() ... Browse Code »

    The documentation for the parameters of blink_set() was a bit hard
    to find so put some where I'd expected to find it.

    Signed-off-by: Mark Brown
    Signed-off-by: Richard Purdie

    Mark Brown
     

06 Apr, 2009

2 commits

09 Jan, 2009

1 commit

08 Jan, 2009

1 commit

21 Oct, 2008

1 commit

  • 326bb8a5a   leds: Make default trigger fields const ... Browse Code »

    The default_trigger fields of struct gpio_led and thus struct
    led_classdev are pretty much always assigned from a string literal,
    which means the string can't be modified. Which is fine, since there is
    no reason to modify the string and in fact it never is.

    But they should be marked const to prevent such code from being added,
    to prevent warnings if -Wwrite-strings is used, when assigned from a
    constant string other than a string literal (which produces a warning
    under current kernel compiler flags), and for general good coding
    practices.

    Signed-off-by: Trent Piepho
    Signed-off-by: Richard Purdie

    Trent Piepho
     

23 Jul, 2008

2 commits

25 Apr, 2008

3 commits

20 Apr, 2008

1 commit

  • b844eba29   PM: Remove destroy_suspended_device() ... Browse Code »

    After 2.6.24 there was a plan to make the PM core acquire all device
    semaphores during a suspend/hibernation to protect itself from
    concurrent operations involving device objects. That proved to be
    too heavy-handed and we found a better way to achieve the goal, but
    before it happened, we had introduced the functions
    device_pm_schedule_removal() and destroy_suspended_device() to allow
    drivers to "safely" destroy a suspended device and we had adapted some
    drivers to use them. Now that these functions are no longer necessary,
    it seems reasonable to remove them and modify their users to use the
    normal device unregistration instead.

    Signed-off-by: Rafael J. Wysocki
    Acked-by: Pavel Machek
    Signed-off-by: Greg Kroah-Hartman

    Rafael J. Wysocki
     

07 Feb, 2008

1 commit

06 Feb, 2008

1 commit

07 Dec, 2007

1 commit

12 Sep, 2007

1 commit

23 Jul, 2007

1 commit

  • d7f5e3df3   Merge branch 'for-linus' of git://git.o-hand.com/linux-rpurdie-leds ... Browse Code »

    * 'for-linus' of git://git.o-hand.com/linux-rpurdie-leds:
    leds: Convert from struct class_device to struct device
    leds: leds-gpio for ngw100
    leds: Add warning printks in error paths
    leds: Fix trigger unregister_simple if register_simple fails
    leds: Use menuconfig objects II - LED
    leds: Teach leds-gpio to handle timer-unsafe GPIOs
    leds: Add generic GPIO LED driver

    Linus Torvalds
     

17 Jul, 2007

1 commit

16 Jul, 2007

2 commits

30 Sep, 2006

1 commit