From: Pavel Machek <pavel@ucw.cz>
To: Jean-Jacques Hiblot <jjhiblot@ti.com>
Cc: jacek.anaszewski@gmail.com, linux-leds@vger.kernel.org,
linux-kernel@vger.kernel.org, tomi.valkeinen@ti.com
Subject: Re: [PATCH v7 2/2] leds: Add control of the voltage/current regulator to the LED core
Date: Wed, 4 Dec 2019 13:37:57 +0100 [thread overview]
Message-ID: <20191125163738.GC3816@amd> (raw)
In-Reply-To: <20191021174751.4421-3-jjhiblot@ti.com>
[-- Attachment #1: Type: text/plain, Size: 3097 bytes --]
Hi!
> A LED is usually powered by a voltage/current regulator. Let the LED core
> know about it. This allows the LED core to turn on or off the power supply
> as needed.
>
> Because turning ON/OFF a regulator might block, it is not done
> synchronously but done in a workqueue. Turning ON the regulator is
> always
How will this interact with LEDs that can be used from atomic context?
> +static ssize_t regulator_auto_off_store(struct device *dev,
> + struct device_attribute *attr, const char *buf, size_t size)
> +{
> + struct led_classdev *led_cdev = dev_get_drvdata(dev);
> + ssize_t ret = size;
> + bool auto_off;
> +
> + if (strncmp(buf, "enable\n", size) == 0)
> + auto_off = true;
> + else if (strncmp(buf, "disable\n", size) == 0)
> + auto_off = false;
> + else
> + return -EINVAL;
Sounds like device power management to me. Is it compatible with that?
> @@ -135,6 +203,8 @@ static void set_brightness_delayed(struct work_struct *ws)
> (led_cdev->flags & LED_HW_PLUGGABLE)))
> dev_err(led_cdev->dev,
> "Setting an LED's brightness failed (%d)\n", ret);
> +
> + led_handle_regulator(led_cdev);
> }
>
You only modify set_brigthness_delays, so this will not work at all
for non-blocking LEDs, right?
> static void led_set_software_blink(struct led_classdev *led_cdev,
> @@ -189,6 +259,7 @@ static void led_blink_setup(struct led_classdev *led_cdev,
> void led_init_core(struct led_classdev *led_cdev)
> {
> INIT_WORK(&led_cdev->set_brightness_work, set_brightness_delayed);
> + INIT_DELAYED_WORK(&led_cdev->reg_off_work, turn_off_regulator_delayed);
>
Could this re-use the workqueue? Many systems will not need
regulators, so this is overhead...
> + /*
> + * the regulator must be turned off. This cannot be
Use "The", and fix double spaces between must and be.
> + } else if (regulator_on && old == REG_R_OFF_U_OFF) {
> + /*
> + * the regulator must be enabled. This cannot be here
"The"
> + /*
> + * small optimization. Cancel the work that had been started
"Small."
> +#include <linux/regulator/consumer.h>
> +
> +/*
> + * The regulator state tracks 2 boolean variables:
> + * - the state of regulator (or more precisely the state required by
> + * led core layer, as many users can interact with the same regulator).
> + * It is tracked by bit 0.
> + * - the state last asked-for by the LED user. It is tracked by bit 1.
> + */
> +#define REG_R_ON BIT(0)
> +#define REG_U_ON BIT(1)
> +
> +enum { REG_R_OFF_U_OFF = 0,
> + REG_R_ON_U_OFF = REG_R_ON,
> + REG_R_OFF_U_ON = REG_U_ON,
> + REG_R_ON_U_ON = REG_R_ON | REG_U_ON
> +};
That's quite weird use of enum.
> +++ b/include/linux/leds.h
> @@ -149,6 +149,15 @@ struct led_classdev {
>
> /* Ensures consistent access to the LED Flash Class device */
> struct mutex led_access;
> +
> + /* regulator */
"Regulator".
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]
next prev parent reply other threads:[~2019-12-04 12:38 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-10-21 17:47 [PATCH v7 0/2] Subject: [PATCH v7 0/2] leds: Add control of the voltage/current regulator to the LED core Jean-Jacques Hiblot
2019-10-21 17:47 ` [PATCH v7 1/2] dt-bindings: leds: document the "power-supply" property Jean-Jacques Hiblot
2019-10-24 22:51 ` Rob Herring
2019-10-21 17:47 ` [PATCH v7 2/2] leds: Add control of the voltage/current regulator to the LED core Jean-Jacques Hiblot
2019-12-04 12:37 ` Pavel Machek [this message]
2020-04-24 12:47 ` Tomi Valkeinen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20191125163738.GC3816@amd \
--to=pavel@ucw.cz \
--cc=jacek.anaszewski@gmail.com \
--cc=jjhiblot@ti.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-leds@vger.kernel.org \
--cc=tomi.valkeinen@ti.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.