History log of /openbmc/u-boot/drivers/misc/pca9551_led.c (Results 1 – 6 of 6)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
Revision tags: v00.04.15, v00.04.14, v00.04.13, v00.04.12, v00.04.11, v00.04.10, v00.04.09, v00.04.08, v00.04.07, v00.04.06, v00.04.05, v00.04.04, v00.04.03, v00.04.02, v00.04.01, v00.04.00, v2021.04, v00.03.03, v2021.01, v2020.10, v2020.07, v00.02.13, v2020.04, v2020.01, v2019.10, v00.02.05, v00.02.04, v00.02.03, v00.02.02, v00.02.01, v2019.07, v00.02.00, v2019.04, v2018.07
# 83d290c5 06-May-2018 Tom Rini <trini@konsulko.com>

SPDX: Convert all of our single license tags to Linux Kernel style

When U-Boot started using SPDX tags we were among the early adopters and
there weren't a lot of other examples to borrow from. So

SPDX: Convert all of our single license tags to Linux Kernel style

When U-Boot started using SPDX tags we were among the early adopters and
there weren't a lot of other examples to borrow from. So we picked the
area of the file that usually had a full license text and replaced it
with an appropriate SPDX-License-Identifier: entry. Since then, the
Linux Kernel has adopted SPDX tags and they place it as the very first
line in a file (except where shebangs are used, then it's second line)
and with slightly different comment styles than us.

In part due to community overlap, in part due to better tag visibility
and in part for other minor reasons, switch over to that style.

This commit changes all instances where we have a single declared
license in the tag as both the before and after are identical in tag
contents. There's also a few places where I found we did not have a tag
and have introduced one.

Signed-off-by: Tom Rini <trini@konsulko.com>

show more ...


Revision tags: v2018.03, v2018.01, v2017.11
# 2d8d190c 19-Jan-2017 Uri Mashiach <uri.mashiach@compulab.co.il>

status_led: Kconfig migration

Move all of the status LED feature to drivers/led/Kconfig.
The LED status definitions were moved from the board configuration
files to the defconfig files.

TBD: Move a

status_led: Kconfig migration

Move all of the status LED feature to drivers/led/Kconfig.
The LED status definitions were moved from the board configuration
files to the defconfig files.

TBD: Move all of the definitions in the include/status_led.h to the
relevant board's defconfig files.

Tested boards: CL-SOM-AM57x, CM-T335

Signed-off-by: Uri Mashiach <uri.mashiach@compulab.co.il>

show more ...


Revision tags: v2016.07, openbmc-20160624-1, v2016.01-rc1
# e573bdb3 30-Oct-2015 Stefano Babic <sbabic@denx.de>

Merge branch 'master' of git://git.denx.de/u-boot


Revision tags: v2015.10, v2015.10-rc5, v2015.10-rc4, v2015.10-rc3
# 13cfbe51 21-Aug-2015 Bernhard Nortmann <bernhard.nortmann@web.de>

allow LED initialization without STATUS_LED_BOOT

For current U-Boot to initialize status LEDs via status_led_init(), it
is required to have both CONFIG_STATUS_LED and STATUS_LED_BOOT defined.
This m

allow LED initialization without STATUS_LED_BOOT

For current U-Boot to initialize status LEDs via status_led_init(), it
is required to have both CONFIG_STATUS_LED and STATUS_LED_BOOT defined.
This may be a particular concern with GPIO LEDs, where __led_init() is
required to correctly set up the GPIO (gpio_request and
gpio_direction_output). Without STATUS_LED_BOOT the initialization isn't
called, which could leave the user with a non-functional "led" command -
due to the fact that the LED routines in gpio_led.c use gpio_set_value()
just fine, but the GPIO never got set up properly in the first place.

I think having CONFIG_STATUS_LED is sufficient to justify a
corresponding call to status_led_init(), even with no STATUS_LED_BOOT
defined. To do so, common/board_r.c needs call that routine, so it now
is exposed via status_led.h.

Signed-off-by: Bernhard Nortmann <bernhard.nortmann@web.de>
[trini: Add dummy __led_init to pca9551_led.c]
Signed-off-by: Tom Rini <trini@konsulko.com>

show more ...


Revision tags: v2015.10-rc2, v2015.10-rc1, v2015.07
# f5df36d0 06-Jul-2015 Stefan Roese <sr@denx.de>

misc: led: pca9551_led: Fix problem with multiple blink frequencies

Only 2 frequencies are supported. The current driver implementation does
not always use the 2 last configured blink frequencies. T

misc: led: pca9551_led: Fix problem with multiple blink frequencies

Only 2 frequencies are supported. The current driver implementation does
not always use the 2 last configured blink frequencies. This patch
fixes this problem. So that the last two entered frequencies are
active.

Signed-off-by: Stefan Roese <sr@denx.de>
Cc: Fabio Estevam <fabio.estevam@freescale.com>
Cc: Tom Rini <trini@konsulko.com>

show more ...


Revision tags: v2015.07-rc3, v2015.07-rc2, v2015.07-rc1, v2015.04, v2015.04-rc5, v2015.04-rc4
# 1cdd9412 12-Mar-2015 Stefan Roese <sr@denx.de>

misc: led: Add PCA9551 LED driver

This patch adds a driver for the PCA9551 LED controller.

Originated-by: Timo Herbrecher <t.herbrecher@gateware.de>
Signed-off-by: Stefan Roese <sr@denx.de>
Reviewe

misc: led: Add PCA9551 LED driver

This patch adds a driver for the PCA9551 LED controller.

Originated-by: Timo Herbrecher <t.herbrecher@gateware.de>
Signed-off-by: Stefan Roese <sr@denx.de>
Reviewed-by: Tom Rini <trini@konsulko.com>
Cc: Fabio Estevam <festevam@gmail.com>
Reviewed-by: Fabio Estevam <fabio.estevam@freescale.com>

show more ...