| Age | Commit message (Collapse) | Author |
|---|
|
This IP is also used on some arm SoC, so we allow to
use it on arm bcm68360 too.
Signed-off-by: Philippe Reynes <philippe.reynes@softathome.com>
|
|
Allow the led bcm6858 driver to be used on bcm63158.
They have the same led controller.
Signed-off-by: Philippe Reynes <philippe.reynes@softathome.com>
|
|
The driver add the support of the led IP on bcm6858.
This led IP can drive up to 32 leds, and can handle
blinking.
Signed-off-by: Philippe Reynes <philippe.reynes@softathome.com>
Reviewed-by: Daniel Schwierzeck <daniel.schwierzeck@gmail.com>
|
|
This patch save common LED property "default-state" value
in post bind of LED uclass.
The configuration for this default state is only performed when
led_default_state() is called;
It can be called in your board_init()
or it could added in init_sequence_r[] in future.
Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>
|
|
This reverts commit bc882f5d5c7b4d6ed5e927bf838863af43c786e7.
because this patch adds the probe of LED driver during the
binding phasis. It is not allowed in driver model because
the drivers (clock, pincontrol) needed by the LED driver can
be also probed before the binding of all the device and
it is a source of problems.
Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>
|
|
In the device tree, the address for the led is located
in the parent node (for exemple leds), not in the led node
(for exemple led@0).
The commit "led: bcm6328: convert to use live dt"
(sha1: 899455176058d673887a762aa38853188a030af4)
change this behaviour and read the address in the led node.
We fix this by reading the base address for led
in the parent node.
Signed-off-by: Philippe Reynes <philippe.reynes@softathome.com>
|
|
Signed-off-by: Álvaro Fernández Rojas <noltari@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Daniel Schwierzeck <daniel.schwierzeck@gmail.com>
|
|
Signed-off-by: Álvaro Fernández Rojas <noltari@gmail.com>
Reviewed-by: Daniel Schwierzeck <daniel.schwierzeck@gmail.com>
|
|
To avoid board specificy LED activation code, automatically
activate gpio-leds with "default-state" property during bind().
Signed-off-by: Patrick Bruenn <p.bruenn@beckhoff.com>
|
|
Add support for the device tree property "default-state". This feature
might be useful for LEDs indicating "power on" or similar states.
Note: Even with this commit gpio-leds remain in reset state. That's
because the led_gpio is not probed until DM_FLAG_ACTIVATED is set.
Signed-off-by: Patrick Bruenn <p.bruenn@beckhoff.com>
|
|
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>
|
|
We have a large number of places where while we historically referenced
gd in the code we no longer do, as well as cases where the code added
that line "just in case" during development and never dropped it.
Signed-off-by: Tom Rini <trini@konsulko.com>
|
|
Adjust this function to us an ofnode instead of an offset, so it can be
used with livetree. This involves updating all callers.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
These support the flat device tree. We want to use the dev_read_..()
prefix for functions that support both flat tree and live tree. So rename
the existing functions to avoid confusion.
In the end we will have:
1. dev_read_addr...() - works on devices, supports flat/live tree
2. devfdt_get_addr...() - current functions, flat tree only
3. of_get_address() etc. - new functions, live tree only
All drivers will be written to use 1. That function will in turn call
either 2 or 3 depending on whether the flat or live tree is in use.
Note this involves changing some dead code - the imx_lpi2c.c file.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
This driver is a simplified version of linux/drivers/leds/leds-bcm6358.c
Signed-off-by: Álvaro Fernández Rojas <noltari@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
|
|
This driver is a simplified version of linux/drivers/leds/leds-bcm6328.c,
simplified to remove HW leds and blink fallbacks.
Signed-off-by: Álvaro Fernández Rojas <noltari@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
|
|
Allow LEDs to be blinked if the driver supports it. Enable this for
sandbox so that the tests run.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Ziping Chen <techping.chan@gmail.com>
|
|
Add support for toggling an LED into the uclass interface. This can be
efficiently implemented by the driver.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Ziping Chen <techping.chan@gmail.com>
|
|
It is useful to be able to read the LED as well as write it. Add this to
the uclass and update the GPIO driver.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Ziping Chen <techping.chan@gmail.com>
|
|
At present this is very simple, supporting only on and off. We want to
also support toggling and blinking. As a first step, change the name of
the main method and use an enum to indicate the state.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Ziping Chen <techping.chan@gmail.com>
|
|
These structures are normally named with 'uc' instead of 'uclass'. Change
this one for consistency.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Ziping Chen <techping.chan@gmail.com>
|
|
There should be a blank line between each option. Add one before LED_GPIO.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Ziping Chen <techping.chan@gmail.com>
|
|
At present devices use a simple integer offset to record the device tree
node associated with the device. In preparation for supporting a live
device tree, which uses a node pointer instead, refactor existing code to
access this field through an inline function.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
Move all of the status LED feature to drivers/led/Kconfig.
doc/README.LED updated to reflect the Kconfig implementation.
Tested boards: CL-SOM-AM57x, CM-T335
Signed-off-by: Uri Mashiach <uri.mashiach@compulab.co.il>
|
|
At present SPL does not have its own option. But these features can
increase SPL code size. Adjust the Kconfig and Makefile so that
separate a SPL option can be selected.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
|
|
The menuconfig for drivers are getting more and more cluttered
and unreadable because too many entries are displayed in a single
flat menu. Use hierarchic menu for each category.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
[trini: Update to apply again in a few places, drop USB hunk]
Signed-off-by: Tom Rini <trini@konsulko.com>
|
|
Add a test to confirm that we can adjust LEDs using the led_gpio driver.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
We normally use -ENODEV for a missing device, rather than -ENOENT. The
latter is reserved for when we have a device but cannot find something
within it.
Also avoid looking at the root LED device since it is only a container.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
Add a simple driver which allows use of LEDs attached to GPIOs. The linux
device tree binding is used.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
Add a simple uclass for LEDs, so that these can be controlled by the device
tree and activated when needed. LEDs are referred to by their label.
This implementation requires a driver for each type of LED (e.g GPIO, I2C).
Signed-off-by: Simon Glass <sjg@chromium.org>
|
