Skip to content

K
Kernel

openeuler / Kernel
1 年多 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 20 9月, 2016 2 次提交
  3. 15 9月, 2016 8 次提交
  5. 17 8月, 2016 3 次提交
  7. 15 8月, 2016 1 次提交
    • H
      leds: is31fl319x: 1/3/6/9-channel light effect led driver · 8c40b7d0
      由 H. Nikolaus Schaller 提交于 
      This is a driver for the Integrated Silicon Solution Inc. LED driver
chips series IS31FL319x. They can drive 1, 3, 6  or up to 9
LEDs.

Each LED is individually controllable in brightness (through pwm)
in 256 steps so that RGB LEDs can show any of ca. 16 Mio colors.

The maximum current of the LEDs can be programmed and limited to
5 .. 40mA through a device tree property.

The chip is connected through I2C and can have one of 4 addresses
in the range 0x64 .. 0x67 depending on how the AD pin is connected. The
address is defined by the reg property as usual.

The chip also has a shutdown input which could be connected to a GPIO,
but this driver uses software shutdown if all LEDs are inactivated.

The chip also has breathing and audio features which are not fully
supported by this driver.

Tested-on: OMAP5 based Pyra handheld prototype.
Signed-off-by: NH. Nikolaus Schaller <hns@goldelico.com>
Signed-off-by: NAndrey Utkin <andrey_utkin@fastmail.com>
Signed-off-by: NJacek Anaszewski <j.anaszewski@samsung.com>
      8c40b7d0
  9. 23 7月, 2016 1 次提交
  11. 19 7月, 2016 2 次提交
  13. 18 7月, 2016 1 次提交
  15. 15 7月, 2016 1 次提交
  17. 11 7月, 2016 1 次提交
    • R
      leds: leds-gpio: Set of_node for created LED devices · bff23714
      由 Rafał Miłecki 提交于 
      When working with Device Tree we iterate over children of "gpio-leds"
compatible node and create LED device for each of them. We take care of
all common DT properties (label, default trigger, state, etc.), however
some triggers may want to support more of them.

It could be useful for timer trigger to support setting delay on/off
values with Device Tree property. Or for transient trigger to support
e.g. duration property.

We obviously should handle such properties in triggers, not in generic
code. To let trigger drivers read properties from DT node we need to set
of_node to point the relevant node. This change allows using all kind of
of helpers in e.g. "activate" callbacks.
Signed-off-by: NRafał Miłecki <zajec5@gmail.com>
Signed-off-by: NJacek Anaszewski <j.anaszewski@samsung.com>
      bff23714
  19. 04 7月, 2016 1 次提交
  21. 29 6月, 2016 1 次提交
  23. 20 6月, 2016 2 次提交
  25. 08 6月, 2016 2 次提交
    • L
      leds: handle suspend/resume in heartbeat trigger · 5ab92a7c
      由 Linus Walleij 提交于 
      The following phenomena was observed: when suspending the
system, sometimes the heartbeat LED was left on, glowing and
wasting power while the rest of the system is asleep, also
disturbing power dissapation measures on the odd suspend
cycle when it's left on.

Clearly this is not how we want the heartbeat trigger to
work: it should turn off and leave the LED off during
system suspend.

This removes the heartbeat trigger when preparing suspend and
restores it during resume. The trigger code will make sure all
LEDs are left in OFF state after removing the trigger, and
will re-enable the trigger on all LEDs after resuming.

Cc: linux-pm@vger.kernel.org
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
Reviewed-by: NUlf Hansson <ulf.hansson@linaro.org>
Signed-off-by: NJacek Anaszewski <j.anaszewski@samsung.com>
      5ab92a7c
    • T
      leds: core: Fix brightness setting upon hardware blinking enabled · 7cfe749f
      由 Tony Makkiel 提交于 
      Commit 76931edd ("leds: fix brightness changing when software blinking
is active") changed the semantics of led_set_brightness() which according
to the documentation should disable blinking upon any brightness setting.
Moreover it made it different for soft blink case, where it was possible
to change blink brightness, and for hardware blink case, where setting
any brightness greater than 0 was ignored.

While the change itself is against the documentation claims, it was driven
also by the fact that timer trigger remained active after turning blinking
off. Fixing that would have required major refactoring in the led-core,
led-class, and led-triggers because of cyclic dependencies.

Finally, it has been decided that allowing for brightness change during
blinking is beneficial as it can be accomplished without disturbing
blink rhythm.

The change in brightness setting semantics will not affect existing
LED class drivers that implement blink_set op thanks to the LED_BLINK_SW
flag introduced by this patch. The flag state will be from now on checked
in led_set_brightness() which will allow to distinguish between software
and hardware blink mode. In the latter case the control will be passed
directly to the drivers which apply their semantics on brightness set,
which is disable the blinking in case of most such drivers. New drivers
will apply new semantics and just change the brightness while hardware
blinking is on, if possible.

The issue was smuggled by subsequent LED core improvements, which modified
the code that originally introduced the problem.

Fixes: f1e80c07 ("leds: core: Add two new LED_BLINK_ flags")
Signed-off-by: NTony Makkiel <tony.makkiel@daqri.com>
Signed-off-by: NJacek Anaszewski <j.anaszewski@samsung.com>
      7cfe749f
  27. 17 5月, 2016 1 次提交
  29. 06 5月, 2016 2 次提交
  31. 19 4月, 2016 3 次提交
  33. 14 4月, 2016 1 次提交
  35. 13 4月, 2016 1 次提交
  37. 30 3月, 2016 1 次提交
  39. 24 3月, 2016 2 次提交
  41. 14 3月, 2016 3 次提交
    • H
      leds: triggers: simplify led_trigger_store · 7296c33e
      由 Heiner Kallweit 提交于 
      led_trigger_store can be significantly simplified by using sysfs_streq().
Signed-off-by: NHeiner Kallweit <hkallweit1@gmail.com>
Signed-off-by: NJacek Anaszewski <j.anaszewski@samsung.com>
      7296c33e
    • A
      leds: max8997: Use devm_led_classdev_register · 1c430f90
      由 Amitoj Kaur Chawla 提交于 
      Switch to resource-managed function devm_led_classdev_register instead
of led_classdev_register and remove unneeded led_classdev_unregister.

Also, remove platform_set_drvdata in probe function and the remove
function, max8997_led_remove as it is now has nothing to do.

The Coccinelle semantic patch used to make this change is as follows:
//<smpl>
@platform@
identifier p, probefn, removefn;
@@
struct platform_driver p = {
  .probe = probefn,
  .remove = removefn,
};

@prb@
identifier platform.probefn, pdev;
expression e;
@@
probefn(struct platform_device *pdev, ...) {
  ...
  e =
- led_classdev_register
+ devm_led_classdev_register
  (...);
   ...
?- led_classdev_unregister(...);
  ...
}
@remove depends on prb@
identifier platform.removefn;
@@
removefn(...) {
...
?- led_classdev_unregister(...);
...
}
//</smpl>
Signed-off-by: NAmitoj Kaur Chawla <amitoj1606@gmail.com>
Signed-off-by: NJacek Anaszewski <j.anaszewski@samsung.com>
      1c430f90
    • A
      leds: da903x: Use devm_led_classdev_register · eed16255
      由 Amitoj Kaur Chawla 提交于 
      Switch to resource-managed function devm_led_classdev_register instead
of led_classdev_register and remove unneeded led_classdev_unregister.

Also, remove platform_set_drvdata in probe function and the remove
function, da903x_led_remove as it is now has nothing to do.

The Coccinelle semantic patch used to make this change is as follows:
//<smpl>
@platform@
identifier p, probefn, removefn;
@@
struct platform_driver p = {
  .probe = probefn,
  .remove = removefn,
};

@prb@
identifier platform.probefn, pdev;
expression e;
@@
probefn(struct platform_device *pdev, ...) {
  ...
  e =
- led_classdev_register
+ devm_led_classdev_register
  (...);
   ...
?- led_classdev_unregister(...);
  ...
}
@remove depends on prb@
identifier platform.removefn;
@@
removefn(...) {
...
?- led_classdev_unregister(...);
...
}
//</smpl>
Signed-off-by: NAmitoj Kaur Chawla <amitoj1606@gmail.com>
Signed-off-by: NJacek Anaszewski <j.anaszewski@samsung.com>
      eed16255