off-delay.
Signed-off-by: Jean-Jacques Hiblot
---
drivers/leds/led-class.c | 156 +--
drivers/leds/led-core.c | 129 +++-
drivers/leds/leds.h | 18 +
include/linux/leds.h | 9 +++
4 files changed, 304 insertions(+), 8
Most of the LEDs are powered by a voltage/current regulator. Describing it
in the device-tree makes it possible for the LED core to enable/disable it
when needed.
Cc: devicet...@vger.kernel.org
To: robh...@kernel.org
To: mark.rutl...@arm.com
Signed-off-by: Jean-Jacques Hiblot
---
Documentation
htness()
changes in v2:
- use devm_regulator_get_optional() to avoid using the dummy regulator and
do some unnecessary work
Jean-Jacques Hiblot (2):
dt-bindings: leds: document the "power-supply" property
leds: Add control of the voltage/current regulator to the LED core
.../dev
On 14/10/2019 20:48, Jacek Anaszewski wrote:
On 10/14/19 2:38 PM, Daniel Thompson wrote:
On Mon, Oct 14, 2019 at 12:49:07PM +0200, Jean-Jacques Hiblot wrote:
On 13/10/2019 14:09, Pavel Machek wrote:
Hi!
I must say I'm not a big fan of this change.
It adds a bunch of code to the LED
On 13/10/2019 14:09, Pavel Machek wrote:
Hi!
I must say I'm not a big fan of this change.
It adds a bunch of code to the LED core and gives small
functionality in a reward. It may also influence maximum
software blinking rate, so I'd rather avoid calling
regulator_enable/disable when timer tr
On 13/10/2019 18:36, Jacek Anaszewski wrote:
On 10/13/19 1:45 PM, Pavel Machek wrote:
Hi!
@@ -112,11 +113,11 @@ tlc591xx_brightness_set(struct led_classdev *led_cdev,
struct tlc591xx_priv *priv = led->priv;
int err;
- switch (brightness) {
+ switch ((int)brightness)
On 09/10/2019 21:26, Rob Herring wrote:
On Wed, Oct 09, 2019 at 10:51:25AM +0200, Jean-Jacques Hiblot wrote:
LED properties must be named "leds" in the same way that PWM, clocks or
PHY properties are names respectively "pwms", "clocks" and "phys".
Cc:
If initialization data is available and its fwnode is actually a of_node,
store this information in the led device's structure. This will allow the
device to use or provide OF-based API such (devm_xxx).
Signed-off-by: Jean-Jacques Hiblot
---
drivers/leds/led-class.c | 4 +++-
1 file chang
Most of the LEDs are powered by a voltage/current regulator. Describing it
in the device-tree makes it possible for the LED core to enable/disable it
when needed.
Signed-off-by: Jean-Jacques Hiblot
---
Documentation/devicetree/bindings/leds/common.txt | 14 ++
1 file changed, 14
done as soon as possible, turning it off can be delayed by setting the
"power-off-delays-ms" property. The intent is to keep the regulator
powered on when the blink rate of the LED is high.
Signed-off-by: Jean-Jacques Hiblot
---
drivers/leds/led-class.c | 21 +++
drivers/leds/
ng the dummy regulator and
do some unnecessary work
Jean-Jacques Hiblot (2):
dt-bindings: leds: document the "power-supply" property
leds: Add control of the voltage/current regulator to the LED core
.../devicetree/bindings/leds/common.txt | 14 ++
drivers/
Sebastian,
On 03/10/2019 13:47, Sebastian Reichel wrote:
Hi,
On Thu, Oct 03, 2019 at 10:28:12AM +0200, Jean-Jacques Hiblot wrote:
From: Tomi Valkeinen
This patch adds a led-backlight driver (led_bl), which is similar to
pwm_bl except the driver uses a LED class driver to adjust the
Jean-Jacques Hiblot
Acked-by: Pavel Machek
---
drivers/leds/led-class.c | 44
include/linux/leds.h | 4
2 files changed, 48 insertions(+)
diff --git a/drivers/leds/led-class.c b/drivers/leds/led-class.c
index c2167b66b61f..455545f5d663 100644
If initialization data is available and its fwnode is actually a of_node,
store this information in the led device's structure. This will allow the
device to use or provide OF-based API such (devm_xxx).
Signed-off-by: Jean-Jacques Hiblot
---
drivers/leds/led-class.c | 5 -
1 file chang
a LED that changes
states quite often (like a mass storage indicator)
JJ
Since AFAIR Pavel was original proponent of this change then
I'd like to see his opinion before we move on to discussing
possible improvements to this patch.
Best regards,
Jacek Anaszewski
On 9/23/19 12:20 PM, Jean
On 23/09/2019 23:03, Jacek Anaszewski wrote:
Hi Jean,
On 9/23/19 11:14 AM, Jean-Jacques Hiblot wrote:
Hi Jacek,
On 20/09/2019 23:10, Jacek Anaszewski wrote:
Hi Jean,
On 9/20/19 2:25 PM, Jean-Jacques Hiblot wrote:
Making led_set_brightness_sync() use led_set_brightness_nosleep() has 2
led_set_brightness_sync() and set_brightness_delayed().
Signed-off-by: Jean-Jacques Hiblot
---
drivers/leds/led-core.c | 13 +++--
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/drivers/leds/led-core.c b/drivers/leds/led-core.c
index f1f718dbe0f8..d318f9b0382d 100644
--- a
led_set_brightness_sync() to work with the non-blocking function
__led_set_brightness()
changes in v2:
- use devm_regulator_get_optional() to avoid using the dummy regulator and
do some unnecessary work
Jean-Jacques Hiblot (3):
led: make led_set_brightness_sync() use led_set_brightness_nosleep()
dt
Most of the LEDs are powered by a voltage/current regulator. Describing it
in the device-tree makes it possible for the LED core to enable/disable it
when needed.
Signed-off-by: Jean-Jacques Hiblot
---
Documentation/devicetree/bindings/leds/common.txt | 6 ++
1 file changed, 6 insertions
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.
Signed-off-by: Jean-Jacques Hiblot
---
drivers/leds/led-class.c | 17 +++
drivers/leds/led-core.c | 65
The TLC chips actually offer 257 levels:
- 0: led OFF
- 1-255: Led dimmed is using a PWM. The duty cycle range from 0.4% to 99.6%
- 256: led fully ON
Signed-off-by: Jean-Jacques Hiblot
---
drivers/leds/leds-tlc591xx.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a
On 20/09/2019 22:29, Jacek Anaszewski wrote:
Hi Jean,
Thank you for the update.
On 9/20/19 1:58 PM, Jean-Jacques Hiblot wrote:
Use devm_led_classdev_register_ext() to pass the fwnode to the LED core.
The fwnode can then be used by the firmware core to create meaningful
names.
Signed-off-by
Hi Jacek,
On 20/09/2019 23:10, Jacek Anaszewski wrote:
Hi Jean,
On 9/20/19 2:25 PM, Jean-Jacques Hiblot wrote:
Making led_set_brightness_sync() use led_set_brightness_nosleep() has 2
advantages:
- works for LED controllers that do not provide brightness_set_blocking()
- When the blocking
Hi Jacek,
On 18/07/2019 19:49, Jacek Anaszewski wrote:
On 7/18/19 3:31 PM, Jean-Jacques Hiblot wrote:
On 18/07/2019 14:24, Jacek Anaszewski wrote:
Hi Jean,
Thank you for the updated patch set.
I have some more comments below.
On 7/17/19 3:59 PM, Jean-Jacques Hiblot wrote:
+static bool
Most of the LEDs are powered by a voltage/current regulator. Describing it
in the device-tree makes it possible for the LED core to enable/disable it
when needed.
Signed-off-by: Jean-Jacques Hiblot
---
Documentation/devicetree/bindings/leds/common.txt | 6 ++
1 file changed, 6 insertions
devm_regulator_get_optional() to avoid using the dummy regulator and
do some unnecessary work
Jean-Jacques Hiblot (3):
led: make led_set_brightness_sync() use led_set_brightness_nosleep()
dt-bindings: leds: document the "power-supply" property
leds: Add control of the voltage/current re
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.
Signed-off-by: Jean-Jacques Hiblot
---
drivers/leds/led-class.c | 17 +++
drivers/leds/led-core.c | 65
led_set_brightness_sync() and set_brightness_delayed().
Signed-off-by: Jean-Jacques Hiblot
---
drivers/leds/led-core.c | 12 +++-
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/drivers/leds/led-core.c b/drivers/leds/led-core.c
index f1f718dbe0f8..50e28a8f9357 100644
--- a
Use devm_led_classdev_register_ext() to pass the fwnode to the LED core.
The fwnode can then be used by the firmware core to create meaningful
names.
Signed-off-by: Jean-Jacques Hiblot
---
drivers/leds/leds-tlc591xx.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a
Use the managed API of the LED class (devm_led_classdev_register()
instead of led_classdev_register()).
This allows us to remove the code used to track-and-destroy the LED devices
Signed-off-by: Jean-Jacques Hiblot
Reviewed-by: Tomi Valkeinen
---
drivers/leds/leds-tlc591xx.c | 84
fixed LED indexing. Previous version did not allow for holes: if n LEDs
were used, they had to be led(0) to led(n-1)
Jean-Jacques Hiblot (2):
leds: tlc591xx: simplify driver by using the managed led API
leds: tlc591xx: use devm_led_classdev_register_ext()
drivers/leds/leds-tlc59
Use the managed API of the LED class (devm_led_classdev_register()
instead of led_classdev_register()).
This allows us to remove the code used to track-and-destroy the LED devices
Signed-off-by: Jean-Jacques Hiblot
Reviewed-by: Tomi Valkeinen
---
drivers/leds/leds-tlc591xx.c | 79
Use devm_led_classdev_register_ext() to pass the fwnode to the LED core.
The fwnode can then be used by the firmware core to create meaningful
names.
Signed-off-by: Jean-Jacques Hiblot
---
drivers/leds/leds-tlc591xx.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a
oles: if n LEDs
were used, they had to be led(0) to led(n-1)
[0]: https://patchwork.kernel.org/project/dri-devel/list/?series=175709
Jean-Jacques Hiblot (2):
leds: tlc591xx: simplify driver by using the managed led API
leds: tlc591xx: use devm_led_classdev_register_ext()
drivers/leds/leds-
On 10/09/2019 22:08, Jacek Anaszewski wrote:
Hi Jean,
Thank you the patch.
On 9/10/19 3:38 PM, Jean-Jacques Hiblot wrote:
The driver parses the device-tree to identify which LED should be handled.
Since the information about the device node is known at this time, we can
provide the LED core
The driver parses the device-tree to identify which LED should be handled.
Since the information about the device node is known at this time, we can
provide the LED core with it. It may be useful later.
Signed-off-by: Jean-Jacques Hiblot
Reviewed-by: Tomi Valkeinen
Acked-by: Pavel Machek
Use the managed API of the LED class (devm_led_classdev_register()
instead of led_classdev_register()).
This allows us to remove the code used to track-and-destroy the LED devices
Signed-off-by: Jean-Jacques Hiblot
Reviewed-by: Tomi Valkeinen
---
drivers/leds/leds-tlc591xx.c | 79
: if n LEDs
were used, they had to be led(0) to led(n-1)
Jean-Jacques Hiblot (2):
leds: tlc591xx: simplify driver by using the managed led API
leds: tlc591xx: Use the OF version of the LED registration function
drivers/leds/leds-tlc591xx.c | 79 +---
1 file
On 10/09/2019 13:26, Daniel Thompson wrote:
endmenu
diff --git a/drivers/video/backlight/Makefile b/drivers/video/backlight/Makefile
index 63c507c07437..2a67642966a5 100644
--- a/drivers/video/backlight/Makefile
+++ b/drivers/video/backlight/Makefile
@@ -57,3 +57,4 @@ obj-$(CONFIG_BACKLIGHT
If the LED is acquired by a consumer device with devm_led_get(), it is
automatically released when the device is detached.
Signed-off-by: Jean-Jacques Hiblot
Acked-by: Pavel Machek
---
drivers/leds/led-class.c | 42
include/linux/leds.h | 2 ++
2
Add DT binding for led-backlight.
Signed-off-by: Jean-Jacques Hiblot
---
.../bindings/leds/backlight/led-backlight.txt | 28 +++
1 file changed, 28 insertions(+)
create mode 100644
Documentation/devicetree/bindings/leds/backlight/led-backlight.txt
diff --git a/Documentation
ed the option to use a GPIO enable.
- removed the option to use a regulator. It should be handled by the LED
core
- don't make any change to the LED core (not needed anymore)
Jean-Jacques Hiblot (2):
leds: Add managed API to get a LED from a device driver
dt-bindings: backlight: Add le
Jean-Jacques Hiblot
Acked-by: Pavel Machek
---
drivers/leds/led-class.c | 50
include/linux/leds.h | 4
2 files changed, 54 insertions(+)
diff --git a/drivers/leds/led-class.c b/drivers/leds/led-class.c
index 4e2af8df5aa8..eb98bf13e53b 100644
From: Tomi Valkeinen
This patch adds a led-backlight driver (led_bl), which is similar to
pwm_bl except the driver uses a LED class driver to adjust the
brightness in the HW. Multiple LEDs can be used for a single backlight.
Signed-off-by: Tomi Valkeinen
Signed-off-by: Jean-Jacques Hiblot
Hi Daniel,
On 09/09/2019 13:14, Daniel Thompson wrote:
On Sat, Sep 07, 2019 at 12:07:27PM +0200, Pavel Machek wrote:
Hi!
I don't see the LED-backlight driver in -next. Could it be pushed? It
is one of last pieces to get working backlight on Motorola Droid 4...
Sorry, I dropped the ball on thi
Hi Rob,
On 24/07/2019 18:47, Rob Herring wrote:
On Mon, Jul 08, 2019 at 12:35:47PM +0200, Jean-Jacques Hiblot wrote:
Most of the LEDs are powered by a voltage/current regulator. describing in
the device-tree makes it possible for the LED core to enable/disable it
when needed.
Signed-off-by
On 18/07/2019 14:24, Jacek Anaszewski wrote:
Hi Jean,
Thank you for the updated patch set.
I have some more comments below.
On 7/17/19 3:59 PM, Jean-Jacques Hiblot wrote:
+static bool __led_need_regulator_update(struct led_classdev *led_cdev,
+ int
Sometimes LEDs are powered by an external voltage/current regulator. Let
the LED core know about it. This allows the LED core to turn on or off
managed power supplies.
Signed-off-by: Jean-Jacques Hiblot
Reviewed-by: Dan Murphy
---
drivers/leds/led-class.c | 15 +
drivers/leds/led
There are some LED drivers that do not implement brightness_set_blocking(),
for those drivers led_set_brightness_sync() cannot work.
Fixing it by calling first __led_set_brightness() and falling back to
__led_set_brightness_blocking() if it failed.
Signed-off-by: Jean-Jacques Hiblot
---
drivers
Sometimes LEDs are powered by a voltage/current regulator. Describing it
in the device-tree makes it possible for the LED core to enable/disable it
when needed.
Signed-off-by: Jean-Jacques Hiblot
Reviewed-by: Dan Murphy
---
Documentation/devicetree/bindings/leds/common.txt | 4
1 file
to a workqueue.
- Fix led_set_brightness_sync() to work with the non-blocking function
__led_set_brightness()
changes in v2:
- use devm_regulator_get_optional() to avoid using the dummy regulator and
do some unnecessary work
Jean-Jacques Hiblot (3):
dt-bindings: leds: document the "po
On 16/07/2019 12:50, Daniel Thompson wrote:
On Mon, Jul 15, 2019 at 05:56:57PM +0200, Jean-Jacques Hiblot wrote:
A LED is usually powered by a voltage/current regulator. Let the LED core
This is almost certainly nitpicking but since there's enough other
review comments that you will ha
Hi Jacek,
On 15/07/2019 22:42, Jacek Anaszewski wrote:
@@ -80,6 +107,7 @@ static void led_timer_function(struct timer_list *t)
}
led_set_brightness_nosleep(led_cdev, brightness);
+ __led_handle_regulator(led_cdev, brightness);
This cannot be called from atomic context since
Hi Dan,
On 15/07/2019 20:59, Dan Murphy wrote:
JJ
On 7/15/19 10:56 AM, Jean-Jacques Hiblot wrote:
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.
This allows the LED core to
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.
Signed-off-by: Jean-Jacques Hiblot
---
drivers/leds/led-class.c | 15
drivers/leds/led-core.c | 50
Most of the LEDs are powered by a voltage/current regulator. Describing it
in the device-tree makes it possible for the LED core to enable/disable it
when needed.
Signed-off-by: Jean-Jacques Hiblot
---
Documentation/devicetree/bindings/leds/common.txt | 6 ++
1 file changed, 6 insertions
devm_regulator_get_optional() to avoid using the dummy regulator and do
some unnecessary work
Jean-Jacques Hiblot (2):
dt-bindings: leds: document the "power-supply" property
leds: Add control of the voltage/current regulator to the LED core
.../devicetree/bindings/leds/common.txt
On 15/07/2019 11:24, Daniel Thompson wrote:
On Mon, Jul 15, 2019 at 11:01:29AM +0200, Jean-Jacques Hiblot wrote:
Hi Dan,
On 12/07/2019 20:49, Dan Murphy wrote:
JJ
On 7/8/19 5:35 AM, Jean-Jacques Hiblot wrote:
A LED is usually powered by a voltage/current regulator. Let the LED
core
Let
Hi Dan,
On 12/07/2019 20:49, Dan Murphy wrote:
JJ
On 7/8/19 5:35 AM, Jean-Jacques Hiblot wrote:
A LED is usually powered by a voltage/current regulator. Let the LED
core
Let the LED core know
about it. This allows the LED core to turn on or off the power supply
as needed.
Signed-off-by
Hi Dan,
On 08/07/2019 20:08, Dan Murphy wrote:
JJ
On 7/8/19 5:06 AM, Jean-Jacques Hiblot wrote:
Use the managed API of the LED class (devm_led_classdev_register()
instead of led_classdev_register()).
This allows us to remove the code used to track-and-destroy the LED
devices
What changed
This series makes it possible for the LED core to manage the power supply
of a LED. It uses the regulator API to disable/enable the power if when the
LED is turned on/off.
This is especially useful in situations where the LED driver/controller is
not supplying the power.
Jean-Jacques Hiblot (2
Most of the LEDs are powered by a voltage/current regulator. describing in
the device-tree makes it possible for the LED core to enable/disable it
when needed.
Signed-off-by: Jean-Jacques Hiblot
---
Documentation/devicetree/bindings/leds/common.txt | 5 +
1 file changed, 5 insertions
A LED is usually powered by a voltage/current regulator. Let the LED core
about it. This allows the LED core to turn on or off the power supply
as needed.
Signed-off-by: Jean-Jacques Hiblot
---
drivers/leds/led-class.c | 10
drivers/leds/led-core.c | 53
Use the managed API of the LED class (devm_led_classdev_register()
instead of led_classdev_register()).
This allows us to remove the code used to track-and-destroy the LED devices
Signed-off-by: Jean-Jacques Hiblot
---
drivers/leds/leds-tlc591xx.c | 79 +---
1
: if n LEDs
were used, they had to be led(0) to led(n-1)
Jean-Jacques Hiblot (2):
leds: tlc591xx: simplify driver by using the managed led API
leds: tlc591xx: Use the OF version of the LED registration function
drivers/leds/leds-tlc591xx.c | 79 +---
1 file
The driver parses the device-tree to identify which LED should be handled.
Since the information about the device node is known at this time, we can
provide the LED core with it. It may be useful later.
Signed-off-by: Jean-Jacques Hiblot
Acked-by: Pavel Machek
---
drivers/leds/leds-tlc591xx.c
Pavel
On 05/07/2019 12:08, Pavel Machek wrote:
Hi!
Also still relevant is whether the LED device is being correctly
modelled if the act of turning on the LED doesn't, in fact, turn the LED
on. Is it *really* a correct implementation of an LED device that
setting it to LED_FULL using sysfs does
Daniel,
On 02/07/2019 11:58, Daniel Thompson wrote:
On Mon, Jul 01, 2019 at 05:14:23PM +0200, Jean-Jacques Hiblot wrote:
From: Tomi Valkeinen
Add DT binding for led-backlight.
I think the patchset is in the wrong order; the DT bindings
documentation should appear *before* the binding is
Use the managed API of the LED class (devm_led_classdev_register()
instead of led_classdev_register()).
This allows us to remove the code used to track-and-destroy the LED devices
Signed-off-by: Jean-Jacques Hiblot
---
drivers/leds/leds-tlc591xx.c | 81 ++--
1
-Jacques Hiblot (2):
leds: tlc591xx: simplify driver by using the managed led API
leds: tlc591xx: Use the OF version of the LED registration function
drivers/leds/leds-tlc591xx.c | 81 ++--
1 file changed, 21 insertions(+), 60 deletions(-)
--
2.17.1
The driver parses the device-tree to identify which LED should be handled.
Since the information about the device node is known at this time, we can
provide the LED core with it. It may be useful later.
Signed-off-by: Jean-Jacques Hiblot
---
drivers/leds/leds-tlc591xx.c | 2 +-
1 file changed
This makes it easier to use pcitest in automated setups.
Signed-off-by: Jean-Jacques Hiblot
---
tools/pci/pcitest.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/tools/pci/pcitest.c b/tools/pci/pcitest.c
index af146bb..5adc8cd 100644
--- a/tools/pci/pcitest.c
+++ b
without
diagnostics is required, the diagnostics can be disabled using a dedicated
ALSA control.
Signed-off-by: Jean-Jacques Hiblot
---
changes in v4:
- rename the control "Auto Diagnostics Swicth" with a capital S on the Switch
sound/soc/codecs/tas6424.c | 13 +++--
sound/soc/code
mute can be connected to GPIO. In that case we have to drive it to the
correct value
Signed-off-by: Jean-Jacques Hiblot
Reviewed-by: Rob Herring
---
.../devicetree/bindings/sound/ti,tas6424.txt | 1 +
sound/soc/codecs/tas6424.c | 37 +-
2
without
diagnostics is required, the diagnostics can be disabled using a dedicated
ALSA control.
Signed-off-by: Jean-Jacques Hiblot
---
sound/soc/codecs/tas6424.c | 13 +++--
sound/soc/codecs/tas6424.h | 4
2 files changed, 15 insertions(+), 2 deletions(-)
diff --git a/sound/soc/codecs
The standby pin can be connected to a GPIO. In that case we have to drive
it to the correct values for the TAS6424 to operate properly.
Signed-off-by: Jean-Jacques Hiblot
Reviewed-by: Rob Herring
---
.../devicetree/bindings/sound/ti,tas6424.txt | 1 +
sound/soc/codecs/tas6424.c
e bindings
Jean-Jacques Hiblot (3):
ASoC: tas6424: Add support for the standby pin
ASoC: tas6424: Add support for the mute pin
ASoC: tas6424: Allow disabling auto diagnostics for faster power-on
.../devicetree/bindings/sound/ti,tas6424.txt | 2 +
sound/soc/codecs
.
Changes in v2:
- use a ALSA control to enable/disable the auto diagnostics instead of
relying on a DTS property.
- fixed typos
- use gpios (plural) instead of gpio in the documentation of the bindings
Jean-Jacques Hiblot (3):
ASoC: tas6424: Add support for the standby pin
ASoC: tas6424
The standby pin can be connected to a GPIO. In that case we have to drive
it to the correct values for the TAS6424 to operate properly.
Signed-off-by: Jean-Jacques Hiblot
---
.../devicetree/bindings/sound/ti,tas6424.txt | 1 +
sound/soc/codecs/tas6424.c | 22
without
diagnostics is required, the diagnostics can be disabled using a dedicated
ALSA control.
Signed-off-by: Jean-Jacques Hiblot
---
sound/soc/codecs/tas6424.c | 19 +--
sound/soc/codecs/tas6424.h | 4
2 files changed, 21 insertions(+), 2 deletions(-)
diff --git a/sound/soc
mute can be connected to GPIO. In that case we have to drive it to the
correct value
Signed-off-by: Jean-Jacques Hiblot
---
.../devicetree/bindings/sound/ti,tas6424.txt | 1 +
sound/soc/codecs/tas6424.c | 37 +-
2 files changed, 37 insertions
On 23/04/2018 17:44, Mark Brown wrote:
On Fri, Apr 20, 2018 at 12:04:42PM +0200, Jean-Jacques Hiblot wrote:
The TAS6424 incorporates both DC-load and AC-load diagnostics which are
used to determine the status of the load. The DC diagnostics runs when any
channel is directed to leave the Hi-Z
mute can be connected to GPIO. In that case we have to drive it to the
correct value
Signed-off-by: Jean-Jacques Hiblot
---
.../devicetree/bindings/sound/ti,tas6424.txt | 1 +
sound/soc/codecs/tas6424.c | 37 +-
2 files changed, 37 insertions
diagnostics is required the DC diagnostics can be bypassed by adding the
property "disable-auto-diagnostics".
Signed-off-by: Jean-Jacques Hiblot
---
.../devicetree/bindings/sound/ti,tas6424.txt | 2 ++
sound/soc/codecs/tas6424.c | 22 +++
. Those diagnosdtics basically serve to
detect :
- wires shorted together
- wire shorted to ground or vbat
- wire disconnected
This is not useful for all platforms and the addition to the startup time is
quite noticeable (230ms).
Jean-Jacques Hiblot (3):
ASoC: tas6424: Allow disabling auto
The standby pin can be connected to a GPIO. In that case we have to drive
it to the correct values for the TAS6424 to operate properly.
Signed-off-by: Jean-Jacques Hiblot
---
.../devicetree/bindings/sound/ti,tas6424.txt | 1 +
sound/soc/codecs/tas6424.c | 22
2017-02-07 20:18 GMT+01:00 Abel Vesa :
> On Wed, Jan 25, 2017 at 07:30:32PM +0100, Jean-Jacques Hiblot wrote:
>
>> Abel, I tested it partially.
>
> OK, so I managed to find exactly what is happening.
>
>> It's seems OK if I have FRAME_POINTER enabled and it breaks
2017-02-10 13:03 GMT+01:00 Abel Vesa :
> On Fri, Feb 10, 2017 at 11:36:12AM +0100, Jean-Jacques Hiblot wrote:
>> 2017-02-09 17:29 GMT+01:00 Russell King - ARM Linux :
>> > On Tue, Feb 07, 2017 at 10:57:55PM +, Abel Vesa wrote:
>> >> +#ifdef CONFIG_DYNAMIC_FTRACE_W
2017-02-09 17:29 GMT+01:00 Russell King - ARM Linux :
> On Tue, Feb 07, 2017 at 10:57:55PM +, Abel Vesa wrote:
>> +#ifdef CONFIG_DYNAMIC_FTRACE_WITH_REGS
>> +
>> +.macro __ftrace_regs_caller
>> +
>> + add ip, sp, #4 @ move in IP the value of SP as it was
>> +
2017-02-07 23:57 GMT+01:00 Abel Vesa :
> The DYNAMIC_FTRACE_WITH_REGS configuration makes it possible for a ftrace
> operation to specify if registers need to saved/restored by the ftrace
> handler.
> This is needed by kgraft and possibly other ftrace-based tools, and the ARM
> architecture is cur
Abel, I tested it partially.
It's seems OK if I have FRAME_POINTER enabled and it breaks otherwise.
My test case attaches a tracing handler to a function "myfunc":
static struct ftrace_ops kprobe_ftrace_ops __read_mostly = {
.func = jjh_ftrace_handler,
.flags = FTRACE_OPS_FL_SAVE_REGS | FTRACE_O
2017-01-12 15:30 GMT+01:00 Jean-Jacques Hiblot :
> 2017-01-12 1:19 GMT+01:00 Abel Vesa :
>> On Tue, Jan 10, 2017 at 04:51:12PM +0100, Petr Mladek wrote:
>>> On Thu 2016-12-08 22:46:55, Abel Vesa wrote:
>>> > On Thu, Dec 08, 2016 at 09:46:35PM +, Abel Vesa wro
2017-01-12 1:19 GMT+01:00 Abel Vesa :
> On Tue, Jan 10, 2017 at 04:51:12PM +0100, Petr Mladek wrote:
>> On Thu 2016-12-08 22:46:55, Abel Vesa wrote:
>> > On Thu, Dec 08, 2016 at 09:46:35PM +, Abel Vesa wrote:
>> > > From: Jean-Jacques Hiblot
>>
2017-01-11 12:18 GMT+01:00 Russell King - ARM Linux :
> On Wed, Jan 11, 2017 at 12:05:05PM +0100, Jean-Jacques Hiblot wrote:
>> 2017-01-11 9:15 GMT+01:00 :
>> > Hi Jean-Jacques,
>> >
>> >> -Original Message-
>> >> From: Jean-Jacques Hiblo
2017-01-11 9:15 GMT+01:00 :
> Hi Jean-Jacques,
>
>> -Original Message-----
>> From: Jean-Jacques Hiblot [mailto:jjhib...@gmail.com]
>> Sent: 2017年1月11日 0:51
>> To: Alexandre Belloni
>> Cc: Wenyou Yang - A41535 ; Mark Rutland
>> ; devicetre
2017-01-10 17:18 GMT+01:00 Alexandre Belloni
:
> I though a bit more about it, and I don't really like the new compatible
> string. I don't feel this should be necessary.
>
> What about the following:
>
> diff --git a/arch/arm/mach-at91/pm.c b/arch/arm/mach-at91/pm.c
> index b4332b727e9c..0333aca63
2016-10-13 15:47 GMT+02:00 Alexandre Belloni
:
> On 13/10/2016 at 14:27:15 +0200, Jean-Jacques Hiblot wrote :
>> 2016-10-13 13:03 GMT+02:00 Alexandre Belloni
>> :
>> > On 12/10/2016 at 14:48:27 +0200, Jean-Jacques Hiblot wrote :
>> >> >
2016-10-13 13:03 GMT+02:00 Alexandre Belloni
:
> On 12/10/2016 at 14:48:27 +0200, Jean-Jacques Hiblot wrote :
>> > +static void at91_lpddr_poweroff(void)
>> > +{
>> > + asm volatile(
>> > + /* Align to cache lines
2016-10-07 18:34 GMT+02:00 Alexandre Belloni
:
> LPDDR memories can only handle up to 400 uncontrolled power off. Ensure the
> proper power off sequence is used before shutting down the platform.
>
> Signed-off-by: Alexandre Belloni
> ---
> drivers/power/reset/at91-poweroff.c | 52
> +++
2016-05-10 14:41 GMT+02:00 Boris Brezillon :
> On Tue, 10 May 2016 12:07:42 +0100
> Mark Rutland wrote:
>
>> On Tue, May 10, 2016 at 10:04:48AM +0200, Boris Brezillon wrote:
>> > On Wed, 4 May 2016 15:35:47 +0200
>> > Boris Brezillon wrote:
>> >
>> > > On Wed, 4 May 2016 08:06:10 -0500
>> > > Rob
1 - 100 of 230 matches
Mail list logo
